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
