This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Help with ivopts
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.