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-bugzi...@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.
