[Bug tree-optimization/22501] [meta-bug] tramp3d-v4 missed optimizations

rguenth at gcc dot gnu dot org gcc-bugzilla@gcc.gnu.org
Fri Jul 15 13:32:00 GMT 2005


------- Additional Comments From rguenth at gcc dot gnu dot org  2005-07-15 13:29 -------
One easy to locate problem (and possibly the one blocking other optimizers
like IVOPTs do anything useful) is aliasing.  From the .vars dump we can see

<L2>:;
  D.215486.D.81558.D.81253.domain_m[0].D.80426.D.50706.D.50587.domain_m = i0.4405;
  D.215486.D.81558.D.81253.domain_m[1].D.80426.D.50706.D.50587.domain_m = i1.4406;
  D.215486.D.81558.D.81253.domain_m[2].D.80426.D.50706.D.50587.domain_m = i2;
  D.215914 = D.215486.D.81558.D.81253.domain_m[0].D.80426.D.50706.D.50587.domain_m;
  D.215816 = D.215486.D.81558.D.81253.domain_m[1].D.80426.D.50706.D.50587.domain_m;
  D.215629 = *(D.215772 + (double *) ((unsigned int) (D.215808 + D.215914 +
D.215816 * D.215806) * 8));

The structure containing an 3-dimensional index into an array D.215486 is
assigned from the integer variables i0, i1, i2 which control a three-level
nested loops.  You can see easily that in the inner loop (whose head you
can see) operations on indices i1 and i2 are not hoisted out of the loop
because aliasing thinks the stores to the structure alias.  Which also
causes us not to propagate the assignments from i0, i1, i2 to the final
use in the memory access.


-- 


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



More information about the Gcc-bugs mailing list