[LLVMdev] Questions for new Backend
sabre at nondot.org
Sun Apr 27 12:48:03 PDT 2008
On Apr 27, 2008, at 7:37 AM, Cédric Venet wrote:
> I am trying to do a backend to a very simple microcontroller. I have
> 1) I have instruction which do "r1 <- r1 op r2", from what I have
> ssen I
> must declare them like:
> let isTwoAddress = 1 in
> def ADD : FopRR< 0b01010,
> (outs CPURegs:$sX), (ins CPURegs:$isX, CPURegs:$sY),
> "ADD $sX, $sY"),
> [(set CPURegs:$sX, (add CPURegs:$isX, CPURegs:
> Where CPURegs is my class of register. I suppose that the pass
> TwoAddressInstructionPass will make the $sX and $isX register the
> same (it
> unify the out reg and the first in reg?) ?
Yes. 'isTwoAddress' is just shorthand for saying that Xs and isX are
constrainted to be tied together. You can constrain any two registers
of the same class with 'Constraints = "$src = $dst"'.
> When should I set isConvertibleToThreeAddress to 1? When I have
> another form
> of the instruction which take a three addresses?
Yes. This is useful when the two address form is more efficient than
the three address form in some way. This will cause the codegen to
prefer the two address form, but fall back to the 3-addr one when it
would otherwise have to insert a copy.
> 2) Instr class contain the following properties. I suppose they must
> be set
> correctly for? I have some question on them. If only '?' I don't
> at all, if no comment then I think I understand.
Take a look at lib/Target/*.td for comments on each of these fields.
> int AddedComplexity = 0; // ?
This is optional, used to tweak instruction selection priority.
> bit isReMaterializable = 0; // ?
Conservatively safe to leave as zero. This will hopefully go away in
> Rq1: If I have a instruction 'add reg, imm' and don't have 'add imm,
> reg' I
> suppose the instruction isn't commutable?
'add' (in the target independent sense) is a commutable operation, so
the code generator will always canonicalize the immediate to the RHS
of the operator. Commutative *instruction* must have two input
register operands, so 'reg,imm' doesn't make sense to be commutative.
> 3) For conditional jump:
> the architecture use the flags carry and zero to do conditional jump
> jump if carry set) and most arithmetic operation set these flags. I
> wondering how to handle this. I have seen some CC (condition code)
> in some
> backend but it is not clear. Or I could model precisely the flag but
> the operations would have more than on output and it seems this isn't
> supported at least in the tablegen? Could you give me some pointer
We don't have wonderful ways of modeling this (i.e. taking advantage
of flags set by random operations) yet, but X86 works the same way.
I'd look at how its backend works.
> 4) IO: on this µC, the IO aren't mapped in the main address space
> and use a
> separate set of load/store. I was thinking of using the new
> functionality of
> multiple address space. But should the separation be done in the
> legalization phase or in the instruction selection phase?
Instruction selection should match on the address space qualifier of
the pointer value in the SrcValue for the load or store.
> Ps: the µC I target is Picoblaze of xilinx:
> I know that having a compiler for a µC this small isn't useful (asm is
> better in this case) but my goal is more too learn how to do a
> backend that
> to really do it.
> And I know there is no indirect jump on this architecture so not all
> code can be legalized.
> In fact I would like to have a template backend for small 8/16 bits
> µC to be
> able to target custom FPGA embedded µC really easily.
This would be an interesting target to add to mainline llvm. It seems
like a great example of a small architecture. We don't have any 8/16
bit arch's and nothing that uses ASI's in mainline yet. It would be
great to have an example.
More information about the llvm-dev