Re: Weird behavior in ivopts code

[Jeffrey A Law <law at redhat dot com>]

On Fri, 2005-03-18 at 18:25 +0100, Zdenek Dvorak wrote:
> Hello,
> 
> > Which appears to walk down the array and try and choose better IV sets.
> > Since it walks down the IV array, which is in SSA_NAME_VERSION order.
> > Thus two loops which are equivalent in all ways except that they use
> > different SSA_NAME_VERSIONs can get different IV sets.
> > 
> > Anyway, the instability of the IV opts code when presented with loops
> > that differ only in the version #s in the SSA_NAMEs they use is really
> > getting in the way of understanding the performance impact of the
> > new jump threading code.  I would expect this instability to also make
> > it difficult to analyze the IVopts in general.
> 
> there's not much to do about the matter.  The choice of ivs in ivopts is
> just a heuristics (and this cannot be changed, due to compiler
> performance reasons), and as such it is prone to such instabilities.
> In fact, both choices of ivs make sense, and they have the same cost
> w.r. to the cost function used by ivopts.
Sigh.  I had a feeling that might be the case.

> 
> Anyway, in this particular case, the patch below should make ivopts
> to prefer the choice of preserving the variable 'i' (which is better
> from the point of preserving debugging information).
Seems reasonable to me given that it preserves debugging information;
it also seems to stabilize IV opts significantly for EON (I was seeing
+-20% performance swings due to this issue for EON).

Consider it pre-approved once you run a bootstrap and regression test.

jeff