[LLVMdev] ARMCodeEmitter.cpp JIT support very broken (2.9 and svn)

Craig Smith craig at ni.com
Tue Aug 30 12:51:22 PDT 2011


I recently tried to update from LLVM 2.8 and 2.9 and ran into several bad issues with JIT support on ARM. 
I ran into several distinct issues so far, and there are probably others.   (None of these problems appear to be fixed in the current svn head either as far as I can tell.)

1) VFP/Neon instructions don't encode correctly at al, because the encoding methods generated by tablegen for them clobber the constructed binary value when they try to implement 'PostEncoderMethod' support , for example, from ARMGenCodeEmitter.inc:

    case ARM::VLDRD:
    case ARM::VSTRD: {
      // op: p
      op = getMachineOpValue(MI, MI.getOperand(3));
      Value |= (op & 15U) << 28;
     // etc ...
      Value = VFPThumb2PostEncoder(MI, Value);         // <--- overwrites Value!
      break;
    }

The bug here is that in utils/TableGen/CodeEmitterGen.cpp, line 196:
	Case += "      Value = " + PostEmitter + "(MI, Value);\n";
should be
	Case += "      Value |= " + PostEmitter + "(MI, Value);\n";

This looks like it would affect all targets, except apparently only ARM uses this feature.

2) ARM BR_JTm and BR_JTadd do not emit because they were changed to PseudoInstructions but the ARMCodeEmitter wasn't updated to compensate.   emitPseudoInstruction() asserts (llvm_unreachable).

3) FCONSTS/FCONSTD also assert similarly.   emitMiscInstruciton which used to support these instructions was removed in r116644.  If you try to add back a case for them in the obvious way, getBinaryCodeForInstr() (which now ostensibly should handle this and has a case for it) asserts constructing the instruction because getMachineOpValue(MI, MI,getOperand(1)) doesn't handle a MachineOperand of type FPImm.

I'm not sure what the right way to fix these last to issues is.

Is any regression testing done at all for JIT support on non-X86 platforms?  It seems like a simple cross-compilation framework could be set up to allow such targets to be sanity-tested without needing an actual CPU to run one.

Thanks





More information about the llvm-dev mailing list