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.
