[Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.

[rakdver at kam dot mff.cuni.cz]

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

--- Comment #8 from rakdver at kam dot mff.cuni.cz <rakdver at kam dot mff.cuni.cz> 2011-11-03 08:06:52 UTC ---
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955
> > 
> > --- Comment #6 from Yuehai Du <duyuehai at gmail dot com> 2011-11-03 06:24:58 UTC ---
> > Let me see if i understand you correctly, you are saying that there isn't an
> > easy way to fix it without hurting the performance(either consider less IV
> > candidates or dumb down the alias analysis). 
> 
> Yes.
> 
> >  so this issue won't be fixed  in trunk now?
> 
> At least I can't see an easy way out.  What I was considering as _maybe_
> a good final solution would be to remove TARGET_MEM_REF and instead
> have TARGET_MEM_REF_ADDR, which would produce an SSA name where we
> could in turn attach alias info to.  The minor downside of that is
> that we lose the ability to directly specify a symbol as the base
> for a TARGET_MEM_REF (which is ironically exactly the point where
> things wreck in this testcase ...)

or we could just start associating alias info with memory references instead
of with pointers.  Either way, this would be a major change.  Anyway, let
me have a look at this, perhaps I can come up with something less intrusive.

> > if in that case, Avoiding the issue by set PARM isn't an option for me.  i
> > still want to fix it in our private port even with an ugly patch. can we just
> > add a new field in MEM_REF which specify it is local or non-nolocal
> > store(enum{INVALID, LOCAL, NON-LOCAL}),  and only set it in IVOPTS before it
> > rewrite the address. we will check this in is_hidden_global_store(). do this
> > work in Gimple level? but i don't know if RTL optimization still delete this
> > store because we don't keep points-to information.
> 
> The issue is not only in is_hidden_global_store (), but the issue
> is that alias analysis thinks the store may only alias the local p1
> array.  Thus you may as well get miscompiles from RTL scheduling as well.
> You could already paper over the issue in question by checking
> if a TARGET_MEM_REF has TMR_OFFSET or TMR_OFFSET2 != NULL_TREE in
> is_hidden_global_store ().  Another way would be to make sure we
> bias costs enough to make the situation less likely, for example
> in get_computation_cost_at, make the address_p code unconditional.

Making a miscompilation "less likely" is really not a good idea; we need to
really fix the problem, even if it means some performance penalty.