[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