Re: fwprop and CSE const anchor opt

[Richard Sandiford <rdsandiford at googlemail dot com>]

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