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