Re: RFC patch: invariant addresses too cheap

[Michael Matz <matz@suse.de>]

Hi,

On Sat, 28 Nov 2009, Richard Sandiford wrote:

> > Hmm.  Looking at the example in that PR, am I right in thinking that 
> > the x86 backend says that the (%rdi,%rax,4) and 16(%rsp,%rax,4) 
> > addresses have the same cost?  It looks that way from the code, and 
> > fwprop wouldn't have made the substitution otherwise, right?
> >
> > If so, why do they have equal cost, given that replacing one address 
> > with the other led to such a drastic performance drop?
> >
> > (I know I'm missing something here, sorry.)
> 
> But without understanding the answer to the question in my earlier mail,
> it still seems to me that this whole idea of checking for cheap
> addresses in loop-invariant.c is tackling things in the wrong way.

The answer to your questions are: yes, you're right.  It is so to generate 
better code, because as the comment in front of ix86_address_cost says, 
it's better on x86 to generate more complex addresses than to load them 
into registers, hence a constant offset isn't taken into account, neither 
is a scaling.  (To say the truth, on some micro architectures addresses 
that use all components are tougher to the decoder).  In the past we even 
made more complex addresses _cheaper_ than simple one (!), which is, well 
..., wrong ;-) but once generated better code.

Unfortunately these target knobs are more an art than a science, and 
defining them in a logical way derivable from hardware manuals often leads 
to suboptimal code :-/

Having said that, I'm not sure why the answer to this question matters 
to you: neither the PR33928 testcase, nor 410.bwaves was about (reg,reg,4) 
vs. ofs(reg,reg,4).  The former was about ofs(reg) vs ofs2(reg) and the 
latter was about (reg) vs (reg,reg).

FWIW I'd also say that fwprop2 would be a good place to sink invariants 
generally (so that loop-invariant could hoist them as it wants).  But I 
don't see how that will get rid of having to compute an absolute cheapness 
(as fwprop2 would only want to sink the invariantes into cheap places).


Ciao,
Michael.