Re: Help with ivopts

[Michael Matz <matz at suse dot de>]

Hi,

On Wed, 6 Jul 2011, Richard Sandiford wrote:

> > 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?

Well, some targets can hide this addition also in other instructions not 
necessarily only for accessing memory (e.g. the lea instruction on x86).
That has to be described in the cost function.

> > 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.

Yes, I think for your example this should be regarded as addresses.

> 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.


Ciao,
Michael.