Help with ivopts
Richard Sandiford
richard.sandiford@linaro.org
Wed Jul 6 13:43:00 GMT 2011
Richard Sandiford <richard.sandiford@linaro.org> writes:
> Michael Matz <matz@suse.de> writes:
>> On Wed, 6 Jul 2011, Richard Sandiford wrote:
>>> If so, then:
>>>
>>> (a) That doesn't happen at the tree level. The subtraction is still inside
>>> the loop at RTL generation time.
>>>
>>> (b) What's the advantage of introducing a new hoisted subtraction that
>>> is going to be live throughout the loop, and then adding another IV
>>> to it inside the loop, over using the original IV and incrementing it
>>> in the normal way?
>>
>> It can reduce address complexity for one of the addresses. E.g. given:
>>
>> i=0; i < end; i+=4
>> p[i];
>> q[i];
>>
>> -->
>>
>> n=p; n < p+end; n+=4
>> [n];
>> (q-p)[n];
>>
>> Here (q-p) is loop-invariant, and the complexity of the first address is
>> lower (no offset). In fact the register pressure is lower by one too
>> (three instead of four, including the end/p+end bound).
>
> But your second loop isn't what I was comparing it with. I was comparing
> it with:
>
> n=p; n < p+end; n+=4, m+=4
> [n]
> [m]
>
> That has the same number of registers (3) and the same number of
> additions (2). And the [m] is what we started with, so it was
> actually:
>
> i=0; i<count; i+=1, n+=4, m+=4
> [n]
> [m]
>
> -->
>
> i=0; i<count; i+=1, n+=4
> [n]
> (q-p)[n]
>
> (we don't get rid of "i" or "count" in this case.
>
> 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). So I'm not
sure when it's a win even on targets like x86.
Richard
More information about the Gcc
mailing list