[Bug lto/55118] New: Missed forward propagation of addresses

[Bug lto/55118] New: Missed forward propagation of addresses

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55118

             Bug #: 55118
           Summary: Missed forward propagation of addresses
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: hubicka@gcc.gnu.org


When compiling tramp3d we end up overestimating function bodies because many of
array accesses and C++ casts are split into multiple instructions. I.e.:

  _3 = &expr_1(D)->left_m;
                freq:1.00 size:  1 time:  1
                Will be eliminated by inlining
                Accounting size:1.00, time:1.00 on new predicate:(op0 changed)
&& (not inlined)
  _5 = LeafFunctor<Field<UniformRectilinearMesh<MeshTraits<3, double,
UniformRectilinearTag, CartesianTag, 3> >, double, BrickView>, EvalLeaf<3>
>::apply (_3, f_4(D));
                freq:1.00 size:  4 time: 13

here left_m is IMO the first field of the structure so _3 will compile to no
code and should have size 1.  But I do not see why it is not an function
argument.

Other common pattern is 
  _5 = &MEM[(const struct Domain *)&D.660972].D.123571.domain_m[i_4].D.118841;
                freq:3.00 size:  1 time:  1
                Accounting size:1.00, time:3.00 on predicate:(true)
  _6 = &MEM[(struct Domain *)_1(D)].D.123571.domain_m[i_4].D.118841;
                freq:3.00 size:  1 time:  1
                Accounting size:1.00, time:3.00 on predicate:(true)
  _7 = MEM[(const Element_t[2] &)_5];
                freq:3.00 size:  1 time:  1
                Accounting size:1.00, time:3.00 on predicate:(true)

where _5 can be folded into _7 computation.

it is easy to search for "= &" occurences in the dump and most of them are
foldable.

Honza

[Bug lto/55118] Missed forward propagation of addresses

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55118

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2012-10-29
             Blocks|54776                       |
         AssignedTo|unassigned at gcc dot       |rguenth at gcc dot gnu.org
                   |gnu.org                     |
     Ever Confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> 2012-10-29 15:37:53 UTC ---
I will investigate what we can do.  I ripped out the old propagation stuff
because we miscompiled things.

The first case cannot be simplified without "lowering" &expr_1(D)->left_m
to expr_1(D) which will cause issues with __builtin_object_size handling.

The 2nd case is because we cannot express dereferencing _5 with TBAA
type Element_t[2] when trying to "inline-expand" it's address.  That is,

MEM[(const Element_t[2] &) &MEM[(const struct Domain
*)&D.660972].D.123571.domain_m[i_4].D.118841 ];

does not simplify because of the variable-offset address.  The only case
we can simplify it is if D.118841 has type Element_t[2] but this is usually
not the case as far as I remember.

I'll still look into the details.

[Bug lto/55118] Missed forward propagation of addresses

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55118

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> 2012-10-30 11:11:35 UTC ---
We can't really do much here without breaking type-based alias analysis and
data dependence analysis (which depends on seeing only array-refs when they
were present in the original source).

Which means that it is eventually worth considering to lower the address
forms some more (even the rare case we combine them with dereferences in
forwprop is suspicious).

Thus, lower

  <bb 3>:
  # i_66 = PHI <i_16(3), 0(2)>
  _12 = &MEM[(const struct Domain *)_10 +
32B].D.119657.domain_m[i_66].D.114927;
  _13 = &MEM[(struct Domain *)this_1(D) + 8B].D.119657.domain_m[i_66].D.114927;
  _14 = MEM[(const Element_t[2] &)_12];
  MEM[(Element_t[2] &)_13][0] = _14;
  _15 = MEM[(const Element_t[2] &)_12 + 4];
  MEM[(Element_t[2] &)_13][1] = _15;
  i_16 = i_66 + 1;
  if (i_16 != 3)
    goto <bb 3>;

to sth like

  tem = i_66 * 4;
  tem = tem + 32;
  _12 = _10 + tem;

nothing for 4.8 though.  And it will badly interact with __builtin_object_size
again.