From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64313 invoked by alias); 9 Jul 2015 19:30:38 -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 64303 invoked by uid 89); 9 Jul 2015 19:30:37 -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,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS 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: mx1.redhat.com Message-ID: <1436469764.24803.156.camel@surprise> Subject: Re: Filed PR jit/66812 for the code generation issue From: David Malcolm To: Dibyendu Majumdar Cc: jit@gcc.gnu.org Date: Thu, 01 Jan 2015 00:00:00 -0000 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> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-SW-Source: 2015-q3/txt/msg00055.txt.bz2 On Thu, 2015-07-09 at 01:12 +0100, Dibyendu Majumdar wrote: > 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) Ah, ok. > 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. FWIW, I suspect that this is effectively just papering over the problem, and that it will come back to bite us, just with a more complicated reproducer :( Does something like: function x(some_arg) local IX if ((some_arg or true) and false) then IX = true end; return ((some_arg or true) and false) end assert(x() == false) exhibit the bug? (have never programmed Lua, so this probably even isn't syntactically correct, but hopefully you get the idea, with const-propagation of 10's value and typecode lots of code gets optimized away, so using an arg of unknown type to thwart that and hopefully get the bug to re-manifest itself). (Note that I've managed to isolate a minimal reproducer for the problem, as noted in another mail this thread)