Adam Nemet <ane...@caviumnetworks.com> writes: > Richard Sandiford writes: >> If we have an instruction: >> >> A: (set (reg Z) (plus (reg X) (const_int 0xdeadbeef))) >> >> we will need to use something like: >> >> (set (reg Y) (const_int 0xdead0000)) >> (set (reg Y) (ior (reg Y) (const_int 0xbeef))) >> B: (set (reg Z) (plus (reg X) (reg Y))) >> >> But if A is in a loop, the Y loads can be hoisted, and the cost >> of A is effectively the same as the cost of B. In other words, >> the (il)legitimacy of the constant operand doesn't really matter. > > My guess is that A not being a recognizable insn, this is relevant at RTL > expansion. Is this correct?
Yeah. It might happen elsewhere too, in conjunction with things like emit_move_insn. >> In summary, the current costs generally work because: >> >> (a) We _usually_ only apply costs to arbitrary instructions >> (rather than candidate instruction patterns) before >> loop optimisation. > > I don't think I understand this point. I see the part that the cost is > typically queried before loop optimization but I don't understand the > distinction between "arbitrary instructions" and "candidate instruction > patterns". Can you please explain the difference? Well, I suppose I should have said something like "arbitrary pattern" or "arbitrary expression" rather than "arbitrary instruction". I just mean "taking the cost of something without trying to recognise the associated instructions". And by "taking the cost of candiate instruction patterns" I mean "taking the cost of something and also recognising it". >> E.g. suppose we're deciding how to implement an in-loop multiplication. >> We calculate the cost of a multiplication instruction vs. the cost of a >> shift/add sequence, but we don't consider whether any of the backend-specific >> shift/add set-up instructions could be hoisted. This would lead to us >> using multiplication insns in cases where we don't want to. >> >> (This was one of the most common situations in which the zero cost helped.) > > I am not sure I understand this. Why would we decide to hoist suboperations > of a multiplication? If it is loop-variant then even the suboperations are > loop-variant whereas if it is loop-invariant then we can hoist the whole > operation. What am I missing? You're probably right. I might be misremembering what the motivating case was. Richard
