RFC patch: invariant addresses too cheap

[Michael Matz]

Hi,

On Wed, 2 Dec 2009, Richard Sandiford wrote:

> > 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).
> 
> Well, the point was that if fwprop2 is allowed to make the substitution,
> it would solve both of the problems you list.  And that seems like
> conceptually the right fix.  But as Paolo says, allowing fwprop2 to make
> the substitution would regress PR30907, because of the costs issue above.

Ah, that was what the ofs(reg,reg,4) was about.  Yeah, according to the 
optimization guide this shouldn't be slower on K8 or K10, but well, 
reality trumps paper :)

> But fwprop.c compares "before" and "after" costs, and I was thinking it 
> should do the same in this case too (if allowed to).  No absolute cost 
> checks should be needed.

Oh, right, of course.

>   (a) fwprop could once again propagate invariants into loops and
>   (b) when it did so, it could ask for a stricter cost, so that we don't
>       inadvertently replace one loop instruction with a more expensive
>       loop instruction (as we did in 30907).
...
> But it might be nice to have a separate mode that's
> suitable for forward-propagating values into blocks of higher frequency,
> along the lines of (b).  Does that sound reasonable?

IMO yes.

> [ Having said that, although I could try to write a patch along
>   those lines, I'm not sure I could test it very well. ;(  I don't
>   have access to things like SPEC. ]

We could test SPEC test patches, but we don't have Nullstone anymore.


Ciao,
Michael.