On 10/03/11 17:26, Richard Sandiford wrote:
> are necessarily equivalent to:
>
> Loop 3:
> A
> B A
> C B A
> D C B A
> A D C B
> B A D C
> C B A D
> D C B A
> D C B
> D C
> D
Sort of. The insns wouldn't rotate like this in a modulo-scheduled loop.
> Is that right? So if D from iteration N*4 of loop 1 doesn't alias A
> from iteration N*4+1 of loop 1 (meaning loop 2 is correct) then it
> follows that the D from any iteration M doesn't alias A from M+1
> (meaning loop 3 is correct? I'm still not convinced that follows
> for sufficiently clever alias analysis.
Is there any reason to believe that gcc does sufficiently clever alias
analysis? Again, think RTL loop unrolling, if you unroll 3 times
A1
B1
A2
B2
A3
B3
then you get identical insns An as well as Bn, and I don't believe
you'll ever get rtl alias analysis to answer differently for pairs
(B1/A2) and (B2/A3). So if there is a way for any of these pairs to
alias in any iteration, it must always detect the conflict.
Also consider that the code in sched-deps doesn't know which loop
iteration it is. Imagine a fully unrolled loop; insns Xn are identical
for a given X and all n. It doesn't matter where you put your
N-iteration window that you pass to sched-deps; since it doesn't know
about the initial conditions, it must act as if it could be from any
start iteration.
Put another way: unless I see a testcase that demonstrates otherwise, I
don't believe there is a problem. If there were a problem, it would be
with the alias analysis rather than the scheduling code.
> Reason for asking is that (AIUI) SMS used to use stronger memory
> disambiguation, but had to pull back to something more conservative
> for similar reasons.
Pointers? All I could find is a thread where rth seems to be of the same
opinion as me:
http://gcc.gnu.org/ml/gcc/2004-09/msg01648.html
Bernd
