[LLVMdev] Register Class assignment for integer and pointer types

[David Chisnall]

On 24 Jun 2013, at 04:50, 杨勇勇 <triple.yang at gmail.com> wrote:

> 2013/6/23 David Chisnall <David.Chisnall at cl.cam.ac.uk>
> Hi,
> 
> In our version of LLVM, we've added different-sized iPTR* types, so we have an iPTR256 for our fat pointers.  This causes some problems with constraints, because the way that TableGen resolves constraints is not expected to handle multiple pointer types.  We've added a flag that can be set on a per-backend basis to turn this off. 
> 
> Our problem is perhaps a bit different form yours, as our pointers must be loaded and manipulated via special instructions, they can not use the integer instructions or registers.
> 
> In our processor, addresses (i.e. pointers) must be assigned to a specific kind of registers before it can be used for memory access, which is the common part between yours and ours.

Ah, you only have one kind of pointer?  This is a difference with our architecture.  We have a set of addressing modes that are implicitly indirected through one of the address registers and so we have two different sizes of pointer with different instructions operating on them.

> Here are 2 possible solutions for our problem:
> 1. constrain instruction selection.
> 1.1  use    "addRegisterClass(MVT::iPTR,  XXX::PTRRegClass);" to bind pointers and their register class.
> 1.2  add a pass to transform ISelDAG before instruction selection. Since we can determine from opcodes whether an operation can only take address registers as its input operands, we replace i32 with iPTR if so, and insert reg-reg move operations if necessary. For example, (load reg,  addr:i32) means we read at 'addr' to fill 'reg'. Here, we modify it to (load reg,  addr:iPTR).
> 1.3  in XXXInstrInfo.td, we give (load  reg,   iPTR:$addr) to match pattern.
> 1.4  and finally we "hope" default register allocator do the proper thing.
> 
> 2. add an annotation pass before register allocation.
> 2.1  we treat both integer and pointer as i32, and hence there is just "addRegisterClass(MVT::i32,  XXX::I32RegClass);"
> 2.2  before register allocation we annote operands if they must reside in address register.
> 2.3  register allocation assigns register class according to annotations mentioned in 2.2, and perhaps a custom register allocator has to be implemented.
> 
> Which way do you think is more feasible?

I think either should work as a short-term hack.  Longer term, I'd like to see TableGen lose two assumptions:

1) Pointers are integers
2) All pointers are the same size

This would make it much easier to support architectures with segmented memory model and various GPUs.

David