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