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
