[Bug tree-optimization/48702] [4.6/4.7 Regression] optimization regression with gcc-4.6 on x86_64-unknown-linux-gnu

["xinliangli at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #20 from davidxl <xinliangli at gmail dot com> 2011-05-18 15:51:06 UTC ---
(In reply to comment #19)
> On Tue, 17 May 2011, rakdver at kam dot mff.cuni.cz wrote:
> 
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48702
> > 
> > --- Comment #15 from rakdver at kam dot mff.cuni.cz <rakdver at kam dot mff.cuni.cz> 2011-05-17 19:26:18 UTC ---
> > Hi,
> > 
> > > The following patch fixes the problem. Is it ok?
> > 
> > as a heuristic, this probably makes sense.  Still, it does
> > not fix the problem, just masks it and makes it harder to reproduce,
> 
> Looks similar to my original workaround, no?
> 
> We can actually use something like the aliasing non-pointer base
> Zdenek mentioned upthread.  TARGET_MEM_REF has two index operands
> (where usually TMR_INDEX2 is NULL of TMR_BASE is non-constant).
> So we could build a TARGET_MEM_REF based off TMR_BASE 0B and
> move the non-pointer base to TMR_INDEX2.  The oracle then should
> not be able to disambiguate anything (and also no points-to
> info would be available, which probably doesn't make this the
> very very best idea either).
> 
> Richard.

This is at the cost of making aliasing info conservative which should at least
be modeled in the cost. Given that the alternative iv candidate exist (which
does not require such treatment), discarding the troublesome candidate seems
reasonable to me.

David