[Bug tree-optimization/74585] SRA forces parameters to memory causing awful code generation

["rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74585

--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> ---
On August 12, 2016 3:46:46 PM GMT+02:00, "wschmidt at gcc dot gnu.org"
<gcc-bugzilla@gcc.gnu.org> wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74585
>
>--- Comment #5 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
>(In reply to Richard Biener from comment #1)
>> The issue is not SRA pushing things to memory - it doesn't.  The
>issue is
>> that in the GIMPLE IL the parameter appears as "memory" as it is an
>> aggregate type.
>> 
>> The issue is really RTL expansion of the argument (not sure where
>that's
>> done)
>> which doesn't take into account that we could happily expand
>> 
>>   a$vx0_27 = MEM[(struct  *)&a];
>>   a$vx1_28 = MEM[(struct  *)&a + 16B];
>>   a$vx2_29 = MEM[(struct  *)&a + 32B];
>>   a$vx3_30 = MEM[(struct  *)&a + 48B];
>> 
>> if a is expanded to registers.
>> 
>
>OK, I'll investigate further.  But the assumption that an aggregate
>parameter
>is "memory" seems wrong to me.  SRA is explicitly taking the address of
>a
>parameter which has not previously had its address taken, so it seems
>to me
>that if it's passed in registers this in itself will force it to memory
>on
>procedure entry, despite whatever else is currently going on with
>-fno-tree-sra.  But this is all talk, I need to do some digging to see
>what the
>issues are.  To me the SRA transformation seemed "obviously" :) wrong,
>so I
>stopped looking...

The MEM_REF quoted does not constitute an address-taking of a.  It's the same
semantically as the original component-refs.

Richard.