------- Comment #20 from rguenth at gcc dot gnu dot org 2010-07-07 10:43
-------
(In reply to comment #19)
> Subject: Re: [4.6 regression] RTL loop
> unrolling causes FAIL: gcc.dg/pr39794.c
>
> > > > > I am not sure what you mean -- I may be misunderstanding how rtl
> > > > > alias analysis
> > > > > works, but as far as I can tell, what unroller does (just preserving
> > > > > the
> > > > > MEM_ATTRs) is conservatively correct (so, potentially it may make us
> > > > > believe
> > > > > that there are dependences that are not really present, but it should
> > > > > not cause
> > > > > a wrong-code bug).
> > > >
> > > > Consider this simplified example:
> > > >
> > > > for (i ...)
> > > > {
> > > > /*A*/ t = a[i];
> > > > /*B*/ a[i+1] = t;
> > > > }
> > > > MEM_ATTRS would indicate that memory references in A and B do not alias.
> > >
> > > but this is clearly wrong, since B in iteration X aliases with A in
> > > iteration
> > > X+1.
> > > So, not a problem in unroller.
> >
> > It is not wrong. You have the two identical pointers p = &a[i] and
> > q = p + 1. *p and *q do not alias. Never.
>
> Well, then you have some other definition of aliasing than me. For me, two
> memory references M1 and M2 do not alias, if on every code path, the locations
> accessed by M1 and M2 are different. With this definition, *p and *q may
> alias,
> as the example above shows. What is your definition?
>
My definition is that the two statements in sequence A, B have a
true dependence if stmt B accesses memory written to by A.
Thus, in this context *p and *q do not "alias" (and this is what
the scheduler and every other optimization pass queries).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44838
