Re: Help with ivopts

[Richard Sandiford <rdsandiford@googlemail.com>]

Michael Matz <matz@suse.de> writes:
> On Wed, 6 Jul 2011, Richard Sandiford wrote:
>> 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.
>
> My first example shows that on some targets it can be a win, also in the 
> non-constant case, saving one IV update.  That is the case if the use of 
> IVb can be replaced by IVb+somereg for "free".  Be that addresses or not.
>
>> 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.
>
> It would make things worse for the above mentioned targets.  I actually 
> think this whole special casing of address_p just hides problems 
> elsewhere, namely in the alising machinery (as I hinted, this might 
> actually be solved meanwhile), and certainly in the cost functions of 
> IVopts.  If it's really better to not express a certain use of IVb via 
> ((base_b-base_a)+IVa), then the cost function should say so, not some 
> after-the-fact hackery rejecting this transformation a posteriori.
>
> If this rejection should still be needed for correctness for the aliasing 
> machinery then it should be limited to that one purpose: avoiding wrong 
> code.  It should not be used to avoid generating worse code on some 
> targets.

OK, I suppose I'd better just live with things as they are then.
My main motivation for getting the uses to be considered as addresses
is precisely to trigger the address_p code that you'd like to remove,
so it wouldn't be a permanent fix.

With that code removed, I think we'll still hit the problem that,
all other things being equal (as they appear to be in this case),
we prefer to reuse ivs rather than create new ones.

Richard