From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 108654 invoked by alias); 5 May 2015 18:07:40 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 108602 invoked by uid 89); 5 May 2015 18:07:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mx2.suse.de Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Tue, 05 May 2015 18:07:37 +0000 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id AEEDBACC2; Tue, 5 May 2015 18:07:34 +0000 (UTC) User-Agent: K-9 Mail for Android In-Reply-To: <5548D4D6.508@foss.arm.com> References: <20150505073228.GH1751@tucnak.redhat.com> <5548A174.4010208@foss.arm.com> <5548A327.3080103@foss.arm.com> <5548BBBC.7060000@foss.arm.com> <5548BC73.8030506@foss.arm.com> <20150505125431.GJ1751@tucnak.redhat.com> <5548BF5B.9000904@foss.arm.com> <20150505130650.GK1751@tucnak.redhat.com> <5548C3AB.4050607@foss.arm.com> <20150505142909.GP1751@tucnak.redhat.com> <5548D4A8.4070105@foss.arm.com> <5548D4D6.508@foss.arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Subject: Re: [PATCH] Fix eipa_sra AAPCS issue (PR target/65956) From: Richard Biener Date: Tue, 05 May 2015 18:07:00 -0000 To: Richard Earnshaw ,Jakub Jelinek CC: gcc-patches@gcc.gnu.org,Martin Jambor ,Alan Lawrence Message-ID: <0B1BAF2B-4854-45B2-BD35-C8181CBC4936@suse.de> X-SW-Source: 2015-05/txt/msg00357.txt.bz2 On May 5, 2015 4:33:58 PM GMT+02:00, Richard Earnshaw wrote: >On 05/05/15 15:33, Richard Earnshaw wrote: >> On 05/05/15 15:29, Jakub Jelinek wrote: >>> On Tue, May 05, 2015 at 02:20:43PM +0100, Richard Earnshaw wrote: >>>> On 05/05/15 14:06, Jakub Jelinek wrote: >>>>> On Tue, May 05, 2015 at 02:02:19PM +0100, Richard Earnshaw wrote: >>>>>> In a literal sense, yes. However, even K&R & stdarg have >standard >>>>>> promotion and conversion rules (size < int => int, floats >promoted to >>>>>> double, etc). What are those rules for GCC's overaligned types >(ie >>>>>> where in the docs does it say what happens and how a back-end >should >>>>>> interpret them)? Shouldn't the mid-end be doing that work so as >to >>>>> >>>>> For the middle-end, the TYPE_ALIGN info on expression types is >considered >>>>> useless, you can get there anything. There is no conversion rule >to what >>>>> you get for myalignedint + int, or (myalignedint) int, or (int) >>>>> myalignedint, etc. >>>>> >>>>>> create a consistent view of the values passed into the back-end? >It >>>>>> seems to me that at present the back-end has to be psychic as to >what is >>>>>> really happening. >>>>> >>>>> No, the backend just shouldn't consider TYPE_ALIGN on the scalars, >and it >>>>> seems only arm ever looks at that. >>>>> >>>> >>>> Nothing in the specification for TARGET_FUNCTION_ARG (or any of the >>>> related functions) makes any mention of this... >>> >>> While this requirement isn't documented, it is clearly common sense >or at >>> least something any kind of testing would reveal immediately. >> >> Then clearly no such tests exist in the testsuite :-( >> > >Or, more precisely, no such tests existed in 2008, when the code went >in. That just means that the code was the first that make this matter. BTW, what do other compilers do (I suppose llvm supports the gcc extensions for alignment)? Can llvm and gcc interoperate properly here? Do the cited testcases work with llvm? Richard. > >R. > >> R. >> >>> And it is nothing broken recently (except that with the SRA changes >it hits >>> much more often), looking e.g. at GCC 3.2, I'm seeing that >expand_call is on >>> that testcase also called with pretty random TYPE_ALIGN on the >argument >>> types; we didn't have GIMPLE then, so it is nothing that GIMPLE >brought in. >>> >>> Jakub >>> >>