[LLVMdev] Some backend questions

[Vladimir Prus]

Chris Lattner wrote:

> > 1. The MachineInstrBuilder has methods to add register operand and
> > immediate operand. However, what would be really nice is a method to add
> > Value*.  So, I would write:
> >
> >     BuildMI(*BB, NM::add, 1).add(I.getOperand(0), I.getOperand(1));
> >
> > and depending on whether the passed Value* is contant or instruction, the
> > add method would either add immediate constant or allocate/get new
> > virtual register.
>
> Okay, the problem with this is that the instruction selector is the code
> that is supposed to know what constraints the instructions have.  For
> example, on many architectures, immediates are limited to 13 bits or some
> other small number.  

Yes, I realize that this code can't be 100% target-independent. 

> Also, for virtual regsiters, there is no context to 
> hold the mapping of Value*'s -> vregs: this is what the instruction
> selector is about.
>
> I recommend taking a look at the getReg(*) methods in the X86 instruction
> selector.  The basic code generation stage for an add, boiled down to its
> simplest form, basically looks like this:
>
> void visitAdd(BinaryOperator &B) {
>   unsigned Op0Reg = getReg(B.getOperand(0));
>   unsigned Op1Reg = getReg(B.getOperand(1));
>   unsigned DestReg = getReg(B);
>
>   unsigned Opcode = (get the opcode for the size of the add);
>   BuildMI(<where>, Opcode, 2, DestReg).addReg(Op0Reg).addReg(Op1Reg);
> }
>
> The nice thing about the "getReg" functionality is that it is a member of
> the instruction selector class, so it has the context to store the maps
> and other things needed in it.

Yes, I've seen this method.

> If you do this (which I recommend for the first step), you'll notice that
> it produces pretty horrible code, as all immediates are copied into
> registers before they are used.  In other words, instead of getting:
>
>   R2 = add R1, 17
>
> You'll get:
>
>   R3 = mov 17
>   R2 = add R2, R3

Right... that's what alarmed me in the first place. I though about something 
code which create immediate operand from constant and virtual register from 
Value* which really points to Instruction*. There should also be some 
mechanism to avoid creating two immediate operands, if target does not allow 
that.
    	   
> > 2. Why SSARegMap is called this way. As far as I can see, it's does not
> > implement any mapping, it simply allocates registers given a register
> > class.
>
> You're right, it currently just keeps track of the register class for each
> virtual register.  Eventually it will keep track of which machine
> instruction defines each virtual register as well, at which point it will
> live up to its name. :)

Ok.

> > 3. Maybe, the allocation of virtual registers for Value* should be made
> > more reusable. The X86 backend has the code for that in getReg method in
> > InstSelectSimple.cpp which:
> >
> >    - uses SSARegMap instance
> >    - keeps internal Value* -> register mapping
> >    - copies constants into register when needed
> >
> > At least first two things will be necessary for my backend too. I start
> > to wonder if it makes sense to make a "BasicInstructionSelector" which
> > will have such reusable logic?
>
> That's a good idea, because basically all instruction selectors require
> the same code.  The problem is that the code needs to know how to get an
> immediate/constant into a register as well, which can be very complex on
> some targets.

Right. I though that a virtual method to copy constant to a virtual register 
would work.

> For now, I recommend just copying the code to get something up and running
> quickly.  In the future we can talk about creating a target independent
> helper class once we understand the requirements and constraints better.

Ok, I'll try to.

> > Sorry if the above is not very clear -- I'm only starting to getting
> > underting of LLVM codebase.
>
> Not at all!  Please ask!  

Thanks.

> BTW, what architecture are you targetting? 

That's NM6403 -- an DSP produced by one russian company (http://module.ru).
As I've already said, my interest is in my PhD research -- I plan to run some 
analysis on LLVM representation and assembler for that processor, so it would 
be more convenient if assembler is produced by LLVM, and not the standard 
compiler.

- Volodya