Michael Matz <[email protected]> writes:
> On Wed, 6 Jul 2011, Richard Sandiford wrote:
>> But what I mean is: even with your starting loop, I'm comparing the
>> transformation that this code does with the alternative, but rejected,
>> transformation of simply treating both addresses as separate ivs. I.e.:
>>
>> i=0; i < end; i+=1
>> p + i * step;
>> q + i * step;
>> -->
>> n=p; n < p+end; n+=step
>> n;
>> (q-p) + n;
>>
>> vs.
>>
>> i=0; i < end; i+=1
>> p + i * step;
>> q + i * step;
>> -->
>> n=p; n < p+end; n+=step, m+=step
>> n;
>> m;
>>
>> It seems like, with this extra code, we're going out of our way to do
>> the first, "clever", transformation, instead of doing the second, even
>> though both seem to have the same cost in terms of loop operations and
>> live registers. So what I'm not sure of is when the first
>> transformation is a win over the second.
>
> It's only a strict win on targets where the addition in "(q-p) + n" can be
> hidden in either address generation, or combined with other arithmetic, or
> on all targets if (q-p) is a constant.
Agreed on the constant thing. But is it really valid to account for
address validity in the !address_p case? I.e.
> Otherwise it merely has the same number of adds and live variables. But
> if it weren't for deficiencies in downstream optimizers (not hoisting the
> subtraction) the first variant is at least not worse than the second on
> targets without autoinc. On targets with autoinc obviously the second
> variant is better (if the autoinc really comes for free).
>
> So, sometimes the first is better, sometimes just the same, sometimes
> worse :-) Probably the cost function in ivopts could use some
> improvements taking at least autoinc into account. The valid address
> forms (i.e. if reg+reg is as cheap as reg) should be taken into account
> already.
...we currently only check for things like reg+reg in the address_p case,
which as discussed, is also the case in which we currently don't apply
this transformation for other reasons. The address_p case is also the
one in which we take auto-increment into account.
That goes back to the question in the original message about whether
these uses should be treated as addresses. I suppose the answer's
probably "yes", since only a cast is getting in the way.
But there's still the separate point that, when not considering
addresses, this transformation doesn't seem to be a win, except
in the constant case. I suppose what I'm saying is that the:
if (use->iv->base_object
&& cand->iv->base_object
&& !operand_equal_p (use->iv->base_object, cand->iv->base_object, 0))
return infinite_cost;
condition seems to make sense in the !address_p case too. It shouldn't
make things worse, and may make things better.
Richard
