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:01 UTC

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

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

Craig Topper via llvm-dev

2017-Sep-04 23:23 UTC

head link

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

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

hameeza ahmed via llvm-dev

2017-Sep-04 23:28 UTC

head link

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

Possibly Parallel Threads

Search for more maybe matching 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

Possibly Parallel Threads