[struct-reorg] strip struct frame from one-field structures.

[Richard Guenther]

On Wed, May 21, 2008 at 2:59 PM, Alon Dayan <ALOND@il.ibm.com> wrote:
>
>
> "Richard Guenther" <richard.guenther@gmail.com> wrote on 12/05/2008
> 15:35:22:
>
>> On Mon, May 12, 2008 at 1:41 PM, Alon Dayan <ALOND@il.ibm.com> wrote:
>> >
>> >  This patch extends struct-reorg optimizations with an ability to strip
> a
>> >  structure frame from one-field structures.
>> >
>> >  For example, the variable 'a' of structure type:
>> >
>> >  typedef struct str
>> >  {
>> >         int* a;
>> >  }
>> >  str a;
>> >
>> >  will be replaced with
>> >  int* a;
>> >
>> >  It works for both user-defined and compiler generated structures, as,
> for
>> >  example, those produced after structure peeling.
>> >  The param struct-reorg-strip-struct was added to activate this
>> >  optimization.
>> >
>> >  With this patch we measured additional 15% on 179.art over basic
>> >  struct-reorg on p5.
>>
>> Did you analyze why?  Because ...
>
> It seems that this patch causes loads to move upward.
>
> Unfortunately we cannot reproduce this effect on small testcase, but
> we see it all over the 179.art benchmark.
>
>
> Without the patch:                  With:.
>
> .L192:                                  .L192::
>      lwz 0,0(30)                   lwz 0,0(29)
>      cmpwi 7,0,0                   cmpwi 7,0,0
>      ble 7,.L253                   ble 7,.L253
>      mtctr 0                       mtctr 0
>      lwz 4,20(31)                  lwz 4,20(30)
>      lwz 5,24(31)                  lwz 5,24(30)
>      li 11,0                       li 9,0
>      lwz 6,28(31)                  lwz 6,28(30)
>      lwz 7,32(31)                  lwz 7,32(30)
>      lwz 8,36(31)                  lwz 8,36(30)
>      lwz 10,40(31)                 lwz 10,40(30)
>                                    lwz 11,44(30)
>      lfd 0,0(28)                   lfd 0,0(28)
>      bgt+ 7,.L193                  bgt+ 7,.L193
>      li 12,1                       li 0,1
>      mtctr 12                      mtctr 0
> .L193:                          .L193:
>      lwz 21,44(30)
>      slwi 12,11,3                  slwi 0,9,3
>      addi 11,11,1                  addi 9,9,1
>      stfdx 0,4,12                  stfdx 0,4,0
>
> Apparently, this patch influence scheduler results, probably
> due to some dependences which were released.
> But we did not hit the nail on the head yet.
>
> Danny, can this patch change results of aliasing in some way,
> and thus cause changing scheduler decision?

On the tree level it shouldn't make a difference (you can check
the optimized dump).  I have no idea for the RTL level, but I think
even there we should handle the situation similar.

Richard.