[llvm-dev] Issues in Vector Add Instruction Machine Code Emission
hameeza ahmed via llvm-dev
llvm-dev at lists.llvm.org
Mon Sep 4 16:28:32 PDT 2017
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/20170905/ac7c5577/attachment.html>
More information about the llvm-dev
mailing list