------- Comment #4 from rguenth at gcc dot gnu dot org 2008-12-07 12:40 -------
There is one thing that is on my list to investigate. This is how the
following
impacts hardware prefetchers:
<bb 2>:
pretmp.34_33 = (*b_13(D))[6];
pretmp.34_62 = (*b_13(D))[7];
pretmp.34_88 = (*b_13(D))[8];
pretmp.37_92 = (*b_13(D))[0];
pretmp.39_95 = (*b_13(D))[1];
pretmp.39_97 = (*b_13(D))[2];
pretmp.39_99 = (*b_13(D))[3];
pretmp.39_101 = (*b_13(D))[4];
pretmp.39_103 = (*b_13(D))[5];
D.1523_164 = (*a_9(D))[0];
D.1526_163 = D.1523_164 * pretmp.37_92;
D.1528_194 = (*a_9(D))[3];
D.1531_192 = D.1528_194 * pretmp.39_95;
D.1532_191 = D.1526_163 + D.1531_192;
D.1534_189 = (*a_9(D))[6];
...
that is, should we try to schedule memory loads and stores to be sequential?
It would be interesting to measure the difference in manually unrolled code
with optimal ordering and the ordering generated by the compiler during
unrolling.
Other than that, the above (all loads of b before all uses) certaily increases
register pressure for i?86 too much so you get spills:
flds 24(%ecx)
fstps -24(%ebp)
flds 28(%ecx)
fstps -20(%ebp)
flds 32(%ecx)
fstps -16(%ebp)
flds (%ecx)
flds 4(%ecx)
flds 8(%ecx)
flds 12(%ecx)
fstps -12(%ebp)
...
and the RTL level doesn't know enough about aliasing to do anything about that.
-fschedule-insns manages to improve things somewhat again - but certainly
scheduling of loads/stores at the tree level would be nice (re-assoc only
schedules registers).
In the end this shouldn't be a regression - maybe the early unrolling of the
innermost loop we do changes things enough though.
It is interesting that before PRE the loads from b are in-order, but PRE
insertion places them out-of-order. Huh. Because we iterate over antic
expressions.
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
GCC target triplet| |i?86-*-*
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38434
