[llvm-dev] Issues in Vector Add Instruction Machine Code Emission
Craig Topper via llvm-dev
llvm-dev at lists.llvm.org
Mon Sep 4 16:01:03 PDT 2017
Leave TA. Put both.
~Craig
On Mon, Sep 4, 2017 at 4:00 PM, hameeza ahmed <hahmed2305 at gmail.com> wrote:
> You are right. But when i defined my instruction as follows:
> def P_256B_VADD : I<0xE1, MRMDestReg, (outs VRP_2048:$dst), (ins
> VRP_2048:$src1, VRPIM_2048:$src2),"P_256B_VADD\t{$src1, $src2, $dst|$dst,
> $src1, $src2}", [(set VRP_2048:$dst, (add (v64i32 VRP_2048:$src1), (v64i32
> VRP_2048:$src2)))]>, VEX_4V;
>
> I get opcode conflicts? Then what to do?
>
> On Tue, Sep 5, 2017 at 3:51 AM, Craig Topper <craig.topper at gmail.com>
> wrote:
>
>> That is not correct. You should add VEX_4V. TA tells the X86 encoder that
>> the instruction opcode belongs on the 3 byte opcode 0x0F 0x3A page in the
>> Intel manual.
>>
>> ~Craig
>>
>> On Mon, Sep 4, 2017 at 3:38 PM, hameeza ahmed <hahmed2305 at gmail.com>
>> wrote:
>>
>>> Thank You.
>>>
>>> My add instruction has TA as follows:
>>>
>>> def P_256B_VADD : I<0xE1, MRMDestReg, (outs VRP_2048:$dst), (ins
>>> VRP_2048:$src1, VRPIM_2048:$src2),"P_256B_VADD\t{$src1, $src2,
>>> $dst|$dst, $src1, $src2}", [(set VRP_2048:$dst, (add (v64i32
>>> VRP_2048:$src1), (v64i32 VRP_2048:$src2)))]>, TA;
>>>
>>> so i defined;
>>>
>>> bool HasTA = TSFlags & X86II::TA; in x86MCCodeEmitter.cpp
>>>
>>> then used this condition;
>>>
>>> if(HasTA)
>>> ++SrcRegNum;
>>>
>>> now getting no error.
>>>
>>> please tell me whether my method is correct? Also please confirm this
>>> whether i need to make changes in MC framework to emit binary code of my
>>> vector instructions. So far i made no changes or additions in MC framework
>>> or any of the file (except the above discussed) and still getting the
>>> correct machine code.
>>>
>>> Is it right way?
>>>
>>>
>>>
>>> On Tue, Sep 5, 2017 at 3:29 AM, Craig Topper <craig.topper at gmail.com>
>>> wrote:
>>>
>>>> Does your ADD instruction have VEX_4V or EVEX_4V as part of its
>>>> declaration in the td file?
>>>>
>>>> ~Craig
>>>>
>>>> On Mon, Sep 4, 2017 at 2:11 PM, hameeza ahmed <hahmed2305 at gmail.com>
>>>> wrote:
>>>>
>>>>> Hello,
>>>>> I am trying to emit binary for my implemented vector instructions.
>>>>> Although yet i havent done any change or addition in MC framework, For
>>>>> vector load instruction there are no error coming. But for vector add
>>>>>
>>>>> instruction is something like this;
>>>>>
>>>>> > %R_0_REG2048b_1<def> = P_256B_VADD %R_0_REG2048b_1<kill>,
>>>>> %R_0_REG2048b_0<kill>
>>>>>
>>>>> I am getting the following error:
>>>>>
>>>>> Unknown immediate size
>>>>> UNREACHABLE executed at /lib/Target/X86/MCTargetDesc/X
>>>>> 86BaseInfo.h:574!
>>>>>
>>>>>
>>>>> i made extensive use of gdb and after debugging i found the line
>>>>> with issue in X86MCCodeEmitter.cpp.
>>>>>
>>>>> Here NumOps=3 (all registers). and CurOp is 1st initialized to 0.
>>>>>
>>>>> then, the following code gets executed;
>>>>>
>>>>> case X86II::MRMDestReg: {
>>>>> EmitByte(BaseOpcode, CurByte, OS);
>>>>> unsigned SrcRegNum = CurOp + 1; //SrcRegNum=1
>>>>> EmitRegModRMByte(MI.getOperand(CurOp),
>>>>> GetX86RegNum(MI.getOperand(SrcRegNum)), CurByte,
>>>>> OS);
>>>>> CurOp = SrcRegNum + 1;
>>>>> break;
>>>>> }
>>>>> so here CurOp becomes 2.
>>>>>
>>>>> After this;
>>>>>
>>>>> it comes to;
>>>>> else {
>>>>> // If there is a remaining operand, it must be a trailing
>>>>> immediate. Emit it
>>>>> // according to the right size for the instruction. Some
>>>>> instructions
>>>>> // (SSE4a extrq and insertq) have two trailing immediates.
>>>>> while (CurOp != NumOps && NumOps - CurOp <= 2) {
>>>>> EmitImmediate(MI.getOperand(CurOp++), MI.getLoc(),
>>>>> X86II::getSizeOfImm(TSFlags),
>>>>> getImmFixupKind(TSFlags),
>>>>> CurByte, OS, Fixups);
>>>>> }
>>>>>
>>>>> here CurOp=2 !=NumOps=3 && 3-2<=2
>>>>> so while condition is satisfied and it goes to emitimmediate which is
>>>>> wrong and there prints error message.
>>>>>
>>>>> Since, there are no immediate involved in instruction, it should not
>>>>> go to emitimmediate. How to solve this issue?
>>>>>
>>>>> Please help.
>>>>>
>>>>> Thank You
>>>>>
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170904/0f91a227/attachment-0001.html>
More information about the llvm-dev
mailing list