loop hoisting fails

[Paulo J. Matos]

On 09/02/11 15:07, Ian Lance Taylor wrote:
>
> You need to set TARGET_RTX_COSTS to indicate that this operation is
> relatively expensive.  That should stop combine from generating it.


Thanks, I will give it a try. One of the things that are not as polished 
as it should is exactly the rtx costs. I am writing costs for optimize_size.

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?

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

Any tips on this?

Cheers,

Paulo Matos