From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127080 invoked by alias); 6 May 2015 14:04:43 -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 127056 invoked by uid 89); 6 May 2015 14:04:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 06 May 2015 14:04:41 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id DC5C129; Wed, 6 May 2015 07:04:07 -0700 (PDT) Received: from e105689-lin.cambridge.arm.com (e105689-lin.cambridge.arm.com [10.2.207.32]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 41F4E3F218; Wed, 6 May 2015 07:04:38 -0700 (PDT) Message-ID: <554A1F73.8040704@foss.arm.com> Date: Wed, 06 May 2015 14:04:00 -0000 From: Richard Earnshaw User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Richard Biener , Jakub Jelinek CC: gcc-patches@gcc.gnu.org, Martin Jambor , Alan Lawrence Subject: Re: [PATCH] Fix eipa_sra AAPCS issue (PR target/65956) 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> <0B1BAF2B-4854-45B2-BD35-C8181CBC4936@suse.de> In-Reply-To: <0B1BAF2B-4854-45B2-BD35-C8181CBC4936@suse.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00452.txt.bz2 On 05/05/15 19:07, Richard Biener wrote: > 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. > Exactly. The comment was in response to the suggestion the code wasn't tested. > 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? > We're looking into it. I'm talking to our LLVM team and we'll make sure we have a consistent set of rules. R. > 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 >>>> >>> > >