[LLVMdev] illegal code generated for special architecture

[Tim Northover]

Hi Boris,

On 5 December 2014 at 07:13, Boris Boesler <baembel at gmx.de> wrote:
>  then LLVM generates the target instruction "ADD D1, A1, D0" which is an illegal instruction - all operands have to be data-registers Dx. I've checked more than once, that address-registers are not in the set of data-registers. The generated instruction is not part of my spec.
>
>  I guess this happens, because I replace the TargetFrameIndex by the address-register in eliminateFrameIndex without checking the parent operation (ADD in this case); it would be valid for some load/store instructions, but not for ADD. Can I run some legalization function for the illegal instruction?

This is a fairly common issue. Not necessarily with register classes,
but where different frame-accessing instructions have different
constraints. Existing targets just make sure that only certain
instructions ever get an <fi#N> MachineOperand and check the
MI.getOpcode() value (see rewriteAArch64FrameIndex for example in
lib/Target/AArch64/AArch64InstrInfo.cpp).

It's sometimes even necessary to insert new instructions to handle the
index (e.g. if the offset is too large).

>  I have absolutely no idea why this fails! Why cant LLVM write the operand 0x7fc7a9034e10: i32 = TargetFrameIndex<2> [ID=3] into an address-register (via my eliminateFrameIndex) and then copy it to a data-register, perform the add and copy the result back into an address-register?

I'd be a little worried about the existence of TargetFrameIndex in
pre-ISel code. They should only be created in situations you know the
user will be able to cope with. Otherwise just create a FrameIndex,
and let it go through ISel if needed.

This might also explain why you're ending up with an unexpected "ADD
reg, <fi>, reg" in eliminateFrameIndex.

Cheers.

Tim.