hameeza ahmed via llvm-dev
2017-Sep-05 00:33 UTC
[llvm-dev] Issues in Vector Add Instruction Machine Code Emission
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/X86MCCodeEmitter.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/e752cd8b/attachment-0001.html>
Craig Topper via llvm-dev
2017-Sep-05 00:45 UTC
[llvm-dev] Issues in Vector Add Instruction Machine Code Emission
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/ > X86MCCodeEmitter.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/ee4015ef/attachment.html>
hameeza ahmed via llvm-dev
2017-Sep-05 05:27 UTC
[llvm-dev] Issues in Vector Add Instruction Machine Code Emission
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>
Seemingly Similar Threads
- Issues in Vector Add Instruction Machine Code Emission
- Issues in Vector Add Instruction Machine Code Emission
- Issues in Vector Add Instruction Machine Code Emission
- Issues in Vector Add Instruction Machine Code Emission
- Issues in Vector Add Instruction Machine Code Emission