[LLVMdev] register allocation
Jeroen.Dobbelaere at synopsys.com
Thu Feb 2 08:40:17 PST 2012
Hi Jakob, Jonas et al,
> Jonas wrote:
> > What's more, setting the GPR_CR class to 'not-spillable' would probably do the trick here as we
> > basically do not want to do this, and I would not have to pre-allocate. But there is probably a
> > better way, or?
> I am sorry, I simply don't understand what you are asking for. You might as well suggest that we all
> don't pay taxes. It sounds tempting, but the plan needs some details.
> If the fast register allocator is not working for you, you can use the greedy register allocator in
> -O0 builds by passing -regalloc=greedy. It's not that much slower.
I believe that Jonas wants to have the following:
- A register class specification such that you get the same effect as 'glue code', but without
having to introducing custom nodes and lowering to represent this glue.
I think that 'glue' is today the only solution if you do not want to produce spill code.
In a backend on which I have been working, we have a compare instruction that sets a flag (true or false), and a conditional branch instruction, that jumps if the flag is true.
Initially, I tried to specify this by providing a lowering of the compare instruction :
(CCReg only contains one register)
def CMPEQ : Instr<
(ins IntRegs:$lhs, IntRegs:$rhs),
"cmpeq $lhs, $src",
[(cmpeq IntRegs:$dst, IntRegs:$src)>;
def BCC : Instr<
(ins CCReg:$cc, brtarget:$addr),
[(brcond CCReg:$cc, bb:$addr)]
This worked, but for more complex programs, llvm tries to generate code to move CC and to spill CC.
I was able to get rid of the 'moves' by setting the copycost to -1.
For getting rid of the spills, I was forced to introduce custom nodes, that pass the CC register
Having a property to register classes that identifies a 'glue-like' behavior would make sense to me.
More information about the llvm-dev