This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: fwprop and CSE const anchor opt
Adam Nemet <anemet@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