[LLVMdev] register allocation

Jeroen Dobbelaere Jeroen.Dobbelaere at synopsys.com
Thu Feb 2 08:40:17 PST 2012


Hi Jakob, Jonas et al,

Jakob wrote:
[...]
> 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<
  (outs CCReg:$dst),
  (ins  IntRegs:$lhs, IntRegs:$rhs),
  "cmpeq $lhs, $src",
  [(cmpeq IntRegs:$dst, IntRegs:$src)>;


def BCC : Instr<
  (outs),
  (ins CCReg:$cc, brtarget:$addr),
  "bcc $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
through 'glue'.

Having a property to register classes that identifies a 'glue-like' behavior would make sense to me.

Greetings,

Jeroen Dobbelaere





More information about the llvm-dev mailing list