From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 48538 invoked by alias); 9 Jul 2015 21:14:34 -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 48528 invoked by uid 89); 9 Jul 2015 21:14:34 -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: <1436476001.24803.165.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> <1436469764.24803.156.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/msg00058.txt.bz2 On Thu, 2015-07-09 at 21:52 +0100, Dibyendu Majumdar wrote: > On 9 July 2015 at 20:22, David Malcolm wrote: > >> 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 :( > > > > Yes agree. > > > 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). > > > > Actually that is valid Lua. Since you aren't passing a value to x() > then some_arg will be NIL. In Lua, NIL and false are false, everything > else is true. > The example above works okay as is, and also when I pass 10 to x(). > As usual with certain bugs - only a specific set of circumstances trigger it. > > > > > (Note that I've managed to isolate a minimal reproducer for the problem, > > as noted in another mail this thread) > > > > Yes that is very good news. Hope you will soon discover the root cause. Root cause found: it turns out that part of GCC's alias analysis is deferred to a frontend-specific hook: LANG_HOOKS_GET_ALIAS_SET For C/C++/Objective C this hook allows type-punning when directly accessing unions, and the Ravi code assumes this. I hadn't implemented this hook for libgccjit, so the optimizer assumes that in this sequence of assignments: (1) R1.value_.b = 0; (2) R1.value_.i = CONST0.value_.i; (3) R1.value_.b = 0; that (1) and (3) have the same LHS, but (2) has a different LHS. Hence it assumes that (3) is redundant, due to (1), and optimizes it away. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66812 for more gory details. The fix will be to implement the LANG_HOOKS_GET_ALIAS_SET internal GCC API thus giving libgccjit some rules about aliasing. Some options: (i) make it identical to C. (ii) give the client code some control over this My initial gut feeling is to go with (i).