loop hoisting fails

[Ian Lance Taylor]

"Paulo J. Matos" <pocmatos@gmail.com> writes:

> It is slightly confusing for me the way it works. I have added a debug
> printf in it so I can debug the costs and when they are called and I
> get a list like this:
>
> == RTXCOST[pass]: outer_code rtx => cost rec/done==
>
> And it starts with:
> == RTXCOST[]: UnKnown (const_int 0 [0x0]) => 0 [done]==
> == RTXCOST[]: set (plus:QI (reg:QI 18 [0])
>     (reg:QI 18 [0])) => 4 [rec]==
> == RTXCOST[]: set (neg:QI (reg:QI 18 [0])) => 4 [rec]==
> ...
> == RTXCOST[]: set (set (reg:QI 21)
>     (subreg:QI (reg:SI 14 virtual-stack-vars) 3)) => 4 [rec]==
>
> The first one is the only one that is called with an unknown
> outer_code. All the other seems to have an outer_code set which should
> be the context in which it shows up but then you get things like the
> last line. outer_code is a set but the rtx itself is _also_ a set. How
> is this possible?

SET is more or less a default outer_code, you can just ignore it.

> Now, what's the best way to write the costs? For example, what's the
> cost for a constant? If the rtx is a (const_int 0), and the outer is
> unknown I would guess the cost is 0 since there's no cost in using
> it. However, if the outer_code is set, then the cost depends on where
> I am putting the zero into. If the outer_code is plus, should the cost
> be 0? (since x + 0 = x and the operation will probably be discarded?)

For your processor it sounds like you should make a constant more
expensive than a register for an outer code of SET.  You're right that
the cost should really depend on the destination of the set but
unfortunately I don't know if you will see that.

I agree that costs are unfortunately not very well documented and the
middle-end does not use them in the most effective manner.  It's still
normally the right mechanism to use to control what combine does.

Ian