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

Craig Topper via llvm-dev

2017-Sep-05 05:34 UTC

head link

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

No, its not right. What error were you getting with EVEX/EVEX_4V and TA?

~Craig

On Mon, Sep 4, 2017 at 10:27 PM, hameeza ahmed <hahmed2305 at gmail.com>
wrote:
> 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/20170904/c8a8f013/attachment.html>

hameeza ahmed via llvm-dev

2017-Sep-05 05:36 UTC

head link

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

the output of backtrace is follows:
(gdb) bt
#0  0x00007ffff6b79267 in __GI_raise (sig=sig at entry=6)
    at ../sysdeps/unix/sysv/linux/raise.c:55
#1  0x00007ffff6b7aeca in __GI_abort () at abort.c:89
#2  0x0000000001960700 in llvm::llvm_unreachable_internal (
    msg=0x2224614 "Invalid op prefix!",
    file=0x222411f
"/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp",
line=681)
    at /lib/Support/ErrorHandling.cpp:118
#3  0x0000000000c05c57 in (anonymous
namespace)::X86MCCodeEmitter::EmitVEXOpcodePrefix (this=0x3037d00,
TSFlags=1126109823418401, CurByte=@0x7fffffffae7c: 0,
    MemOperand=1, MI=..., Desc=..., OS=...)
    at /lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp:681
#4  0x0000000000c03add in (anonymous
namespace)::X86MCCodeEmitter::encodeInstruction (this=0x3037d00, MI=...,
OS=..., Fixups=..., STI=...)
    at /lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp:1227
#5  0x00000000015894f3 in llvm::MCELFStreamer::EmitInstToData
(this=0x304db90,
    Inst=..., STI=...)
    at /lib/MC/MCELFStreamer.cpp:478
#6  0x00000000015abe00 in llvm::MCObjectStreamer::EmitInstruction (
    this=0x304db90, Inst=..., STI=...)
    at /lib/MC/MCObjectStreamer.cpp:244
#7  0x00000000007a04ab in llvm::X86AsmPrinter::EmitAndCountInstruction
(this    0x3052950, Inst=...)
    at /lib/Target/X86/X86MCInstLower.cpp:105
#8  0x00000000007a341c in llvm::X86AsmPrinter::EmitInstruction (
    this=0x3052950, MI=0x30a1e10)
    at /lib/Target/X86/X86MCInstLower.cpp:1737
#9  0x0000000000dde5d6 in llvm::AsmPrinter::EmitFunctionBody
(this=0x3052950)
---Type <return> to continue, or q <return> to quit---
    at /lib/CodeGen/AsmPrinter/AsmPrinter.cpp:939
#10 0x0000000000796fc1 in llvm::X86AsmPrinter::runOnMachineFunction (
    this=0x3052950, MF=...)
    at /lib/Target/X86/X86AsmPrinter.cpp:70
#11 0x000000000104d7f1 in llvm::MachineFunctionPass::runOnFunction (
    this=0x3052950, F=...)
    at /lib/CodeGen/MachineFunctionPass.cpp:62
#12 0x00000000014776ff in llvm::FPPassManager::runOnFunction
(this=0x302f5d0,
    F=...) at /lib/IR/LegacyPassManager.cpp:1513
#13 0x0000000001477a15 in llvm::FPPassManager::runOnModule (this=0x302f5d0,
    M=...) at /lib/IR/LegacyPassManager.cpp:1534
#14 0x00000000014781aa in (anonymous namespace)::MPPassManager::runOnModule
(
    this=0x3022d30, M=...)
    at /lib/IR/LegacyPassManager.cpp:1590
#15 0x0000000001477cd6 in llvm::legacy::PassManagerImpl::run
(this=0x301d250,

    M=...) at /lib/IR/LegacyPassManager.cpp:1693
#16 0x00000000014786c1 in llvm::legacy::PassManager::run
(this=0x7fffffffd778,
    M=...) at /lib/IR/LegacyPassManager.cpp:1724
#17 0x000000000076bd1e in compileModule (argv=0x7fffffffdf68, Context=...)
    at /tools/llc/llc.cpp:528
#18 0x000000000076a209 in main (argc=5, argv=0x7fffffffdf68)
    at /tools/llc/llc.cpp:285
(gdb)
(gdb)


On Tue, Sep 5, 2017 at 10:34 AM, Craig Topper <craig.topper at gmail.com>
wrote:
> No, its not right. What error were you getting with EVEX/EVEX_4V and TA?
>
> ~Craig
>
> On Mon, Sep 4, 2017 at 10:27 PM, hameeza ahmed <hahmed2305 at
gmail.com>
> wrote:
>
>> 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/df37a9d7/attachment-0001.html>

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