[llvm-dev] Issues in Vector Add Instruction Machine Code Emission

Craig Topper via llvm-dev llvm-dev at lists.llvm.org
Mon Sep 4 22:34:06 PDT 2017 

No, its not right. What error were you getting with EVEX/EVEX_4V and TA?

~Craig

On Mon, Sep 4, 2017 at 10:27 PM, hameeza ahmed <hahmed2305 at gmail.com> wrote:

> I was getting same error when i keep both EVEX/EVEX_4V and TA. So, i
> restored my original instructions and for that i have to include
>   bool HasTA = TSFlags & X86II::TA; in x86MCCodeEmitter.cpp
>
> then used this condition;
>
> if(HasTA)
>       ++SrcRegNum;
>
> in order to emit binary correctly.
>
> Is it right?
>
> On Tue, Sep 5, 2017 at 5:45 AM, Craig Topper <craig.topper at gmail.com>
> wrote:
>
>> Put the TA's back. EVEX/EVEX_4V does not replace TA. They are for
>> different things. An EVEX/EVEX_4V instruction must use one of T8, TA, XOP8,
>> XOP9, XOPA.
>>
>> ~Craig
>>
>> On Mon, Sep 4, 2017 at 5:33 PM, hameeza ahmed <hahmed2305 at gmail.com>
>> wrote:
>>
>>> Thank You,
>>> I changed TA to EVEX or EVEX_4V. But now i am getting following error:
>>>
>>> Invalid prefix!
>>> UNREACHABLE executed at /lib/Target/X86/MCTargetDesc/X
>>> 86MCCodeEmitter.cpp:647!
>>>
>>>
>>> On Tue, Sep 5, 2017 at 4:36 AM, Craig Topper <craig.topper at gmail.com>
>>> wrote:
>>>
>>>> Not all instructions can use EVEX_4V. Move instructions in particular
>>>> cannot because they don't have 2 sources.
>>>>
>>>> What do you intend to do with the binary output once you have it? You
>>>> don't seem to be targeting a particular binary definition so its
>>>> effectively just random numbers.
>>>>
>>>> ~Craig
>>>>
>>>> On Mon, Sep 4, 2017 at 4:28 PM, hameeza ahmed <hahmed2305 at gmail.com>
>>>> wrote:
>>>>
>>>>> Thank You.
>>>>>
>>>>> I used EVEX_4V with all the instructions. I replaced TA and EVEX both
>>>>> with EVEX_4V. Now, I am getting following error:
>>>>>
>>>>> llvm-tblgen: /utils/TableGen/X86RecognizableInstr.cpp:687: void
>>>>> llvm::X86Disassembler::RecognizableInstr::emitInstructionSpecifier():
>>>>> Assertion `numPhysicalOperands >= 2 + additionalOperands &&
>>>>> numPhysicalOperands <= 4 + additionalOperands && "Unexpected number of
>>>>> operands for MRMSrcMemFrm"' failed
>>>>>
>>>>> What to do now?
>>>>>
>>>>> On Tue, Sep 5, 2017 at 4:23 AM, Craig Topper <craig.topper at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> VEX_4V tells the encoder to use the VEX.vvvv field to encode one of
>>>>>> the operands. Without it the encoder assumes that the destination and one
>>>>>> of the sources must be the same physical register.
>>>>>>
>>>>>> TA indicates which of the opcode maps the instruction belongs to.
>>>>>> This corresponds to encoding 0x3 of the VEX.mmmmm field.
>>>>>>
>>>>>> ~Craig
>>>>>>
>>>>>> On Mon, Sep 4, 2017 at 4:01 PM, hameeza ahmed <hahmed2305 at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Sorry to ask but what does it mean to put both?
>>>>>>>
>>>>>>> On Tue, Sep 5, 2017 at 4:01 AM, Craig Topper <craig.topper at gmail.com
>>>>>>> > wrote:
>>>>>>>
>>>>>>>> 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/c8a8f013/attachment.html>

More information about the llvm-dev mailing list