Constant propagation and CSE

[Jeff Law]

  On 10/27/10 12:15, Frederic Riss wrote:
> Hi Jeff,
>
> On 26 October 2010 16:22, Jeff Law<law@redhat.com>  wrote:
>> There is currently no pass which does "un-cse"; however, using insn
>> splitting and operand costing and suitable insn constraints/predicates  you
>> can usually arrange to avoid expensive constants in places where it makes
>> sense.
> The thing is the cprop pass doesn't look at insn costs while doing its
> job AFAICS. I'm interested to see how insn splitting can help with
> this if you don't care to explain.
Certainly the SSA propagators don't use costing information; CSE on the 
other hand does using costing info, but not always in the way you might 
think (addresses in memory references for example are often backwards 
from what you might think)
>
> The problem is quite simple: if a target allows big immediates in its
> instructions, the cprop pass can generate quite an inflation in code
> size on some kind of codes. Imagine that a 64-bits constant is
> propagated in every iteration of an unrolled loop. For that case, it
> would be much more cache friendly to have the constant in register(s)
> and not propagate it. Do not focus too much on the 'loop unrolling'
> thing, it's just an example of one kind of code that uses the same
> constant a bunch of times.
This is a common problem.  For constants, its generally preferable to 
first load them into registers and allow CSE to try and commonize the 
large constants.  Combine then will propagate single use constants into 
their use, leaving the multi-use constants commonized.

Register pressure isn't as much of a problem as you might think because 
constants are relatively easy to rematerialize when there is excess 
register pressure.

Jeff