This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix eipa_sra AAPCS issue (PR target/65956)
- From: Richard Biener <rguenther at suse dot de>
- To: Richard Earnshaw <Richard dot Earnshaw at foss dot arm dot com>,Jakub Jelinek <jakub at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org,Martin Jambor <mjambor at suse dot de>,Alan Lawrence <alan dot lawrence at arm dot com>
- Date: Tue, 05 May 2015 20:07:29 +0200
- Subject: Re: [PATCH] Fix eipa_sra AAPCS issue (PR target/65956)
- Authentication-results: sourceware.org; auth=none
- References: <20150505073228 dot GH1751 at tucnak dot redhat dot com> <5548A174 dot 4010208 at foss dot arm dot com> <5548A327 dot 3080103 at foss dot arm dot com> <A290B716-CC90-4AB9-A14C-768C7623AA83 at suse dot de> <5548BBBC dot 7060000 at foss dot arm dot com> <5548BC73 dot 8030506 at foss dot arm dot com> <20150505125431 dot GJ1751 at tucnak dot redhat dot com> <5548BF5B dot 9000904 at foss dot arm dot com> <20150505130650 dot GK1751 at tucnak dot redhat dot com> <5548C3AB dot 4050607 at foss dot arm dot com> <20150505142909 dot GP1751 at tucnak dot redhat dot com> <5548D4A8 dot 4070105 at foss dot arm dot com> <5548D4D6 dot 508 at foss dot arm dot com>
On May 5, 2015 4:33:58 PM GMT+02:00, Richard Earnshaw <Richard.Earnshaw@foss.arm.com> 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
>>>
>>