[llvm-commits] [PATCH] ARM JIT: Add support to MOVimm32 using movt/movw for JIT

[Shih-wei Liao]

I agreed with Rafael that the patch is fine. It's more concise than my
29-line patch that I mentioned in my original bug report. E.g., I was
adding in ARMCodeEmitter.cpp the "static inline unsigned rotr32"
function which is unnecessary under Zonr's solution. Luckily I didn't
get time to submit my patch yet, so we can just go ahead with Zonr's
patch below.

I reviewed and tested Zonr's patch and it passed all our tests.
Rafael, if it's OK with you, could you commit Zonr's patch upstream?
LGTM.

On Thu, May 20, 2010 at 8:54 PM, Zonr Chang <zonr.xchg at gmail.com> wrote:
> Sorry, I forgot to attach the patch ... :(
>
> Zonr
>
>
>> 2010/5/21 Zonr Chang <zonr.xchg at gmail.com>
>>
>> Thanks for your patch review (and also to Anton.)
>>
>> How to reuse the movw/movt logic is indeed a problem. PR7048 is an example.
>> To fix this bug, we need to insert more codes into function
>> emitDataProcessingInstruction(...) (see attachment.)
>>
>> It is because, precisely, the previous patch (arm-jit-movt-and-movw.patch)
>> implemented the pseudo instruction ARM::MOVi32imm (which according to
>> ARMInstrInfo.td should be materialized to movw/movt pair.) However, there's
>> a case to use movw or movt as a single instruction to move value and their
>> materialization will route to emitDataProcessingInstruction() since both
>> movw (opcode ARM::MOVTi16) and movt (opcode ARM::MOVi16) are data processing
>> instructions (i.e. ARMII::DPFrm.)
>>
>> In PR7048, the "1001" to printf(...) will be moved to the register using
>> single instruction movw. As you can see in this patch, the logic to encode
>> the immediate is reused the third time (one
>> in emitDataProcessingInstruction(...) and one in relocation codes.)
>>
>> Is there a way to reuse the encoding codes?
>>
>>
>> Zonr
>>