thr3ads.net - llvm dev - [llvm-dev] Issues in Vector Add Instruction Machine Code Emission [Sep 2017]

If this information is useful, please help other people find it:
Share via:

hameeza ahmed via llvm-dev

2017-Sep-04 23:28 UTC

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

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>

Craig Topper via llvm-dev

2017-Sep-04 23:36 UTC

head link

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

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/b5a90c31/attachment.html>

hameeza ahmed via llvm-dev

2017-Sep-05 00:33 UTC

head link

[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>

Seemingly Similar Threads

Search for more possibly parallel threads

llvm dev - Sep 2017 - Issues in Vector Add Instruction Machine Code Emission

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

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

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

Seemingly Similar Threads