From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 52847 invoked by alias); 9 Jul 2015 00:12:59 -0000 Mailing-List: contact jit-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Subscribe: Sender: jit-owner@gcc.gnu.org Received: (qmail 52834 invoked by uid 89); 9 Jul 2015 00:12:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.98.7 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mail-yk0-f173.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=loYsWUHEdRtZgbyjaU85OY4bmQLsE27aNpi18BwXX2I=; b=PWIkjylTMv7VR0rQIfUIVhYMWUcD3rhxjZKz54munkqjpf40qoQuJjxvkCgvTEr1wL K4oDcroQ+hc2dm+D+b/bnMzlhFokTfh0HIH/xjQpI3DQfAP69zVMTAOFdyIA7TivLiJT vEMMd9WwqmwyYi1unNTqBTc3WVxgQaXfGBmVuYkj36I1H7qvEgwWSNhrX9CfM9+WlIFw QEEDskSZF1l+4PL7hjsjdjljg8hxvUbGA5M/9ocXWeLDhKiHolkquRJWF3J2dhXeswkH 4jQx8cqaHIlHuzdHi9Sh83Se74G33C7NFkZ9v963L1s/6V+zZYISicONM1fX3SOV0gxG BC6w== X-Gm-Message-State: ALoCoQkPx0rIBtQLnNzXTpsj0xnN7yV5u3SbFoO1ruSJm4KRlcIPXJC9r2lg7CNl8lBGQLAR0FeA MIME-Version: 1.0 X-Received: by 10.170.87.134 with SMTP id e128mr14212182yka.109.1436400775468; Wed, 08 Jul 2015 17:12:55 -0700 (PDT) In-Reply-To: References: <1436365266.24803.65.camel@surprise> <1436367926.24803.71.camel@surprise> <1436369443.24803.75.camel@surprise> <1436377619.24803.97.camel@surprise> <1436382217.24803.101.camel@surprise> <1436385256.24803.107.camel@surprise> Date: Thu, 01 Jan 2015 00:00:00 -0000 Message-ID: Subject: Re: Filed PR jit/66812 for the code generation issue From: Dibyendu Majumdar To: David Malcolm Cc: jit@gcc.gnu.org Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2015-q3/txt/msg00047.txt.bz2 On 8 July 2015 at 21:06, Dibyendu Majumdar wrote: >> BTW, are Lua/Ravi constants truly constant? If so, then I'd believe >> you'd get a performance win by implementing LOADK by emitting code to >> write the specific tt and value_ directly, rather than code that copies >> a value from the table. > > Yes - I do specialize to constants in certain cases - such as loops > and numeric operations. But more can be done. > >> >> This would enable the optimizer to "know" the tt and value_, and >> optimize accordingly. For example, in this case, I believe it would >> allow the function to be optimized away down to the equivalent of just a >> "return false;". Obviously won't help much for a function without a >> loop, but if it saves instructions inside a loop, that's probably a win. >> >> (...though maybe not before we track down this issue) >> I implemented setting the constant directly (just checked in). Performance wise no noticeable difference (as I think the scenarios where this helps were already covered) but it does seem to have caused the optimization bug to go away - i.e. the tests now pass. I will run more tests tomorrow to see if this is true under all optimization settings. Regards Dibyendu