search for: vex_4v

Yes, there is an easy way to fix this. MRMSrcMem assumes register, memory, vvvv register if VEX_4VOp3 is true and assumes register, vvvv register, memory if VEX_4V is true. I just need to change the flag from VEX_4VOp3 to VEX_4V. There are a few places where we assume only the 2nd operand can be tied-to: Desc->getOperandConstraint(1, MCOI::TIED_TO) != -1 (hard-coded index 1) I will fix those...

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

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

I don't think changing to VEX_4VOp3 to VEX_4V is the right fix. I think the fix is to increment CurOp twice at the start for these instructions so that only the input operands are used for encoding. Also, I just submitted a patch to revert the operand order for these instructions in the assembler/disassembler. Destination registe...

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

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

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 &lt...

...ructions. 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 ha...

On Jul 9, 2012, at 4:15 PM, Manman Ren <mren at apple.com> wrote: > > I need to implement an instruction which has 2 read-write registers, so I added > let Constraints = "$src1 = $dst, $mask = $mask_wb" in { > ... > def rm : AVX28I<opc, MRMSrcMem, (outs VR128:$dst, VR128:$mask_wb), > (ins VR128:$src1, v128mem:$src2, VR128:$mask), > ... > }

...ial X86* operators. This is reflected in X86InstrSSE.td: "Traditional": defm VUNPCKLPS: sse12_unpack_interleave<0x14, unpckl, v4f32, memopv4f32, VR128, f128mem, "unpcklps\t{$src2, $src1, $dst|$dst, $src1, $src2}", SSEPackedSingle>, VEX_4V; "New-style": def : Pat<(v4f32 (X86Unpcklps VR128:$src1, (memopv4f32 addr:$src2))), (VUNPCKLPSrm VR128:$src1, addr:$src2)>, Requires<[HasAVX]>; I think these are basically the same pattern. What's the purpose of these special operators and patterns?...

I need to implement an instruction which has 2 read-write registers, so I added let Constraints = "$src1 = $dst, $mask = $mask_wb" in { ... def rm : AVX28I<opc, MRMSrcMem, (outs VR128:$dst, VR128:$mask_wb), (ins VR128:$src1, v128mem:$src2, VR128:$mask), ... } There is a problem since MRMSrcMem assumes the 2nd physical operand is a memory operand. See the section about

In ToT, LowerVECTOR_SHUFFLE for x86 has this code: if (X86::isUNPCKLMask(SVOp)) getTargetShuffleNode(getUNPCKLOpcode(VT) dl, VT, V1, V2, DAG); why would this not be: if (X86::isUNPCKLMask(SVOp)) return SVOp; I'm trying to add support for VUNPCKL and am getting into trouble because the existing code ends up creating: VUNPCKLPS load load which is badness come selection

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

...2mem, loadi32, "cvtsi2sd\t{$src, $dst, $dst|$dst, $dst, $src}">, XD, VEX; ... } let isAsmParserOnly = 1 in { defm VCVTSI2SD : sse12_vcvt_avx<0x2A, GR32, FR64, i32mem, "cvtsi2sd">, XD, VEX_4V; ... } If this style of modification is OK for people working on x86/AVX .td, I am ready to provide a patch. Or is there any better way? -- Syoyo

...s reflected in X86InstrSSE.td: > > "Traditional": > > defm VUNPCKLPS: sse12_unpack_interleave<0x14, unpckl, v4f32, memopv4f32, > VR128, f128mem, "unpcklps\t{$src2, $src1, $dst|$dst, $src1, $src2}", > SSEPackedSingle>, VEX_4V; > "New-style": > > def : Pat<(v4f32 (X86Unpcklps VR128:$src1, (memopv4f32 addr:$src2))), > (VUNPCKLPSrm VR128:$src1, addr:$src2)>, Requires<[HasAVX]>; > > I think these are basically the same pattern. > > What's the purpose of th...

...fix - Indicates the instruction should be encoded with a 0xF3 rep prefix. OpcEnc - Which encoding scheme this instruction uses. Normal, VEX, EVEX, or XOP. VEX_WPrefix - Controls the value of the VEX.W bit in the encoder also tells the disassembler which instructions ignore VEX.W. hasVEX_4V - Does this instruction use VEX.vvvv hasVEX_L - Should this instruction be encoded with VEX.L=1 ignoresVEX_L - Tells the disassembler that VEX.L should be ignored hasEVEX_K - Does this instruction use a k-register for masking hasEVEX_Z - Is the k-register used for zero ma...

I am attempting to create an instruction which takes a single 64-bit immediate. This doesn't seem like a thing that would exist already (because who needs an instruction which just takes an immediate?) How might I implement this easily? Perhaps I could use a format which encodes a register, which is then unused? Thanks for the help. Gus -------------- next part -------------- An HTML