"Paulo J. Matos" <pocma...@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
