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

[Owen Anderson]

Craig,

On Aug 30, 2011, at 12:51 PM, Craig Smith wrote:
> 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.)

The non-MC-based ARM JIT path is known not to work, and nobody is working on fixing it.  The MC-based instruction encoder is rapidly maturing is generally passable for static encoding, but the MCJIT is still in its infancy.

> 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 is the intended behavior.  The some post-encoder hooks need to clear bits as well as set them.  If you're seeing incorrect output from the post-encoder hook, it's because the hook itself has a bug.

> 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).

This is another symptom of the non-MC ARM JIT being unmaintained.  It is correct for emitPseudoInstruction() to assert.  All pseudo instructions should be expanded before they reach the encoder, and they are properly expanded in the MC-based path.

--Owen