[llvm-commits] [llvm] r116259 - in /llvm/trunk: lib/Target/ARM/ARMAddressingModes.h lib/Target/ARM/ARMBaseInstrInfo.h lib/Target/ARM/ARMInstrInfo.td lib/Target/ARM/ARMMCCodeEmitter.cpp test/MC/ARM/simple-encoding.ll

[Jim Grosbach]

On Oct 11, 2010, at 4:29 PM, Chris Lattner wrote:

> On Oct 11, 2010, at 4:16 PM, Jim Grosbach wrote:
>> +++ llvm/trunk/lib/Target/ARM/ARMMCCodeEmitter.cpp Mon Oct 11 18:16:21 2010
>> @@ -139,8 +140,27 @@
>>    return;
>> 
>>  ++MCNumEmitted;  // Keep track of the # of mi's emitted
>> +  // FIXME: TableGen doesn't deal well with operands that expand to multiple
>> +  // machine instruction operands, so for now we'll fix those up here.
>>  switch (Opcode) {
>> -  //FIXME: Any non-pseudos that need special handling, if there are any...
>> +  case ARM::ADDrs:
>> +  case ARM::ANDrs:
>> +  case ARM::BICrs:
>> +  case ARM::EORrs:
>> +  case ARM::ORRrs:
>> +  case ARM::SUBrs: {
>> +    // The so_reg operand needs the shift ammount encoded.
>> +    unsigned Value = getBinaryCodeForInstr(MI);
>> +    unsigned ShVal = MI.getOperand(4).getImm();
>> +    unsigned ShType = ARM_AM::getShiftOpcEncoding(ARM_AM::getSORegShOp(ShVal));
>> +    unsigned ShAmt = ARM_AM::getSORegOffset(ShVal);
>> +
>> +    Value |= ShType << ARMII::ShiftTypeShift;
>> +    Value |= ShAmt << ARMII::ShiftShift;
> 
> 
> Hi Jim,
> 
> What is the issue here?  Could this be solved by having the generated code emitter pass the MachineOperand's operand # into getMachineOpValue?

We want to be able to have more fine-grained control over the encoding of the operands, as some things like shifted immediates and such need extra logic beyond isImm(), isReg(), et. al. to get the operand encoding values to mask into the instruction encoding. To do this, I want to have a getter method on the operands, very similar to how the PrintMethod is used by the asmwriter. I have a plan to get there, and believe it can be done without backward compatibility issues, so no changes to existing targets should be necessary.

The current special-case implementations in ARMMCCodeEmitter.cpp for the arithmetic instructions are placeholders to give me some simple regression tests for the new bits and as an example of how we can deal with things in the meantime should we need to. I expect them to be pretty short-lived.

-Jim


> 
>> +
>> +    EmitConstant(Value, 4, CurByte, OS);
>> +    break;
>> +  }
>>  default: {
>>    unsigned Value = getBinaryCodeForInstr(MI);
>>    EmitConstant(Value, 4, CurByte, OS);
>> 
>> Modified: llvm/trunk/test/MC/ARM/simple-encoding.ll
>> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/MC/ARM/simple-encoding.ll?rev=116259&r1=116258&r2=116259&view=diff
>> ==============================================================================
>> --- llvm/trunk/test/MC/ARM/simple-encoding.ll (original)
>> +++ llvm/trunk/test/MC/ARM/simple-encoding.ll Mon Oct 11 18:16:21 2010
>> @@ -8,8 +8,8 @@
>> define i32 @foo(i32 %a, i32 %b) nounwind ssp {
>> entry:
>> ; CHECK: foo
>> -; CHECK: 0xf0,0x00,0xf0,0x07
>> -; CHECK: 0x1e,0xff,0x2f,0xe1
>> +; CHECK: trap                         @ encoding: [0xf0,0x00,0xf0,0x07]
>> +; CHECK: bx lr                        @ encoding: [0x1e,0xff,0x2f,0xe1]
>> 
>>  tail call void @llvm.trap()
>>  ret i32 undef
>> @@ -18,9 +18,21 @@
>> define i32 @f2(i32 %a, i32 %b) nounwind readnone ssp {
>> entry:
>> ; CHECK: f2
>> -; CHECK: 0x00,0x00,0x81,0xe0
>> -; CHECK: 0x1e,0xff,0x2f,0xe1
>> +; CHECK: add  r0, r1, r0              @ encoding: [0x00,0x00,0x81,0xe0]
>> +; CHECK: bx lr                        @ encoding: [0x1e,0xff,0x2f,0xe1]
>>  %add = add nsw i32 %b, %a
>>  ret i32 %add
>> }
>> +
>> +
>> +define i32 @f3(i32 %a, i32 %b) nounwind readnone ssp {
>> +entry:
>> +; CHECK: f3
>> +; CHECK: add  r0, r0, r1, lsl #3      @ encoding: [0x81,0x01,0x80,0xe0]
>> +; CHECK: bx lr                        @ encoding: [0x1e,0xff,0x2f,0xe1]
>> +  %mul = shl i32 %b, 3
>> +  %add = add nsw i32 %mul, %a
>> +  ret i32 %add
>> +}
>> +
>> declare void @llvm.trap() nounwind
>> 
>> 
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>