From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 100843 invoked by alias); 4 Jul 2015 22:09:52 -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 100832 invoked by uid 89); 4 Jul 2015 22:09:51 -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-f179.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=ag0x60tASplNqFmoBVuqjDxVLIqKNN4R9k6XDlbXKf0=; b=O4Z8XMjbLPe1aU7+e696rFAuKWWFE8JozlN1DyerB+YgPd1kYrrGKpdY7Thc5U/wdv wjX8Jrrn4xCGk+xe8PUikWIECRyxpQajDgTwgRdBHNvH8R1GAABRAgWL5dt9rcu1cF0i VZccIPuiBnjpdiToswzvB1Fz/aBW6tBwVBp4QfDTlNne6RdcQPiA6+HtVkFrejo3oM4B Yg6A3/dctUjwe49OywQq1RZScyxyK0iD+Z9w32gAzocDZ2aMClzu5LFC1jKkEauCaDzy ElsJmIhSeuVGi94ZMx8/We3brTwDeOe+k4SH0IFlMeBwPNTGaz41m22/+LkCHkGvU6qD Z6Sg== X-Gm-Message-State: ALoCoQlbk0gP4rPh17onnzGhWGj9mkKrI4Fwq7MZedFN93Kek1ZReqfgBhDUGOxvY/0m+Cff+fQj MIME-Version: 1.0 X-Received: by 10.13.204.142 with SMTP id o136mr52296865ywd.171.1436047788507; Sat, 04 Jul 2015 15:09:48 -0700 (PDT) In-Reply-To: <1436046085.24803.35.camel@surprise> References: <1436046085.24803.35.camel@surprise> Date: Thu, 01 Jan 2015 00:00:00 -0000 Message-ID: Subject: Re: A possible 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/msg00017.txt.bz2 On 4 July 2015 at 22:41, David Malcolm wrote: >> Adding the -fno-strict-aliasing appears to resolve the issue with -O2 >> and -O3 but with this enabled the benchmarks are degraded. > > If "-fno-strict-aliasing" resolved this, then that suggests that there > are various casts in the code that if this were C would take us into > "undefined behavior" territory, and the optimizer is trying a little too > hard. This isn't C, but similar rules apply. If that's what this is, > then this is at least a documentation issue with libgccjit; we need to > document what the rules are. > > If this is the case it's normally possible to work around it in C by > rewriting casts using unions. I guess if you can help me work out which bit of code is causing a problem then I can implement a fix. > > Of course, it could well be a bug at my end. > > In any case, I'm not going to be able to have a proper look at this > until Monday (it's the July 4th holiday weekend here in the US); sorry. > No problem - Monday is fine. I have nearly implemented all the Lua bytecodes that I have working in LLVM only a few left to do. Regards Dibyendu