Re: Help with ivopts

[Michael Matz <matz@suse.de>]

Hi,

On Wed, 6 Jul 2011, Richard Sandiford wrote:

> > If the target allows (q-p)[n] to be used directly as an address, and 
> > if the target has no post-increment instruction, then it might be 
> > better. But I think it's a loss on other targets.  It might even be a 
> > loss on targets (like PowerPC IIRC), that need base+index addresses to 
> > have the "real" base first.  This sort of transformation seems to make 
> > us lose track of which register is the base.
> 
> Actually, I take that back.  Use of (p-q)[n] (hoisted_diff[n]) as an 
> address is precisely the case in which we've decided we _don't_ want to 
> apply the optimisation (see the address_p code I quoted).

I know, I was referring to the general case of uses of IVs, not 
necessarily in address context, it was just easier to write.  The reason 
for disabling this in address context is not because of having no 
advantage, but rather because accessing objects without a useful base (and 
"&obj1 - &obj2" is no useful one) in the past lead to wrong aliasing 
answers.  Meanwhile it shouldn't lead to wrong answers anymore, but still 
to less precise ones.

I wrote the example only to show the situation in which such seemingly 
strange transformation (building the difference of unrelated entities) is 
actually helpful.

> So I'm not sure when it's a win even on targets like x86.

In my example (and imaging that p[i] actually stands for some arbitrary 
arithmetic involving the sum of p and i, or if we would remove the 
address_p special case) the transformation is universally a win.  In your 
example it isn't a win because the address operations are as simple as 
possible to start with, and become more complex due to the transformation, 
that would point towards a glitch in the cost analysis. It's still getting 
rid of one induction variable, but I'd agree that that's no advantage with 
post-increment targets, and even without postinc the increased complexity 
of the address makes the transformation dubious.  A better transformation 
would be to get rid of the i induction variable.


Ciao,
Michael.