similar to: Issues in Vector Add Instruction Machine Code Emission

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

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,

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,

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

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

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

Hi, I have a problem with creating a MFENCE on X86 with SSE In X86InstrSSE.td, a MFENCE is def MFENCE : I<0xAE, MRM6m, (outs), (ins), "mfence", [(int_x86_sse2_mfence)]>, TB, Requires< [HasSSE2]>; In X86CodeEmitter.cpp in emitInstruction case X86II::MRM6m: case X86II::MRM7m: { intptr_t PCAdj = (CurOp+4 != NumOps) ?

Hmm. mfence and lfence needs special handling. I'll take a look. Evan On Oct 16, 2008, at 10:46 PM, Mon Ping Wang wrote: > Hi, > > I have a problem with creating a MFENCE on X86 with SSE > > In X86InstrSSE.td, a MFENCE is > def MFENCE : I<0xAE, MRM6m, (outs), (ins), > "mfence", [(int_x86_sse2_mfence)]>, TB, Requires< > [HasSSE2]>;

I've fixed this (untested though). http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20081013/068611.html Evan On Oct 17, 2008, at 9:51 AM, Evan Cheng wrote: > Hmm. mfence and lfence needs special handling. I'll take a look. > > Evan > > On Oct 16, 2008, at 10:46 PM, Mon Ping Wang wrote: > >> Hi, >> >> I have a problem with creating a MFENCE

OK, here's a new patch that adds the infrastructure and the implementation for X86, ARM and PPC of GetInstSize and GetFunctionSize. Both functions are virtual functions defined in TargetInstrInfo.h. For X86, I moved some commodity functions from X86CodeEmitter to X86InstrInfo. What do you think? Nicolas Evan Cheng wrote: > > I think both of these belong to TargetInstrInfo. And

Comments below. On Apr 15, 2008, at 4:24 AM, Nicolas Geoffray wrote: > OK, here's a new patch that adds the infrastructure and the > implementation for X86, ARM and PPC of GetInstSize and > GetFunctionSize. Both functions are virtual functions defined in > TargetInstrInfo.h. > > For X86, I moved some commodity functions from X86CodeEmitter to > X86InstrInfo. >

This attempts to address http://llvm.org/bugs/show_bug.cgi?id=18220 It also fixes a test which was requiring the *wrong* output. I'm relatively happy with this part, and it even solves most of the hard part of feature request for .code16 in bug 8684 — which was actually why I started prodding at this. But I could do with some help with the 16-bit signed relocation handling, which I've

i want to emit binary code for the following implemented vector assembly instructions. P_256B_LOAD_DWORD R_0_R2048b_0, pword ptr [rip + b] P_256B_LOAD_DWORD R_0_R2048b_1, pword ptr [rip + c] P_256B_VADD R_0_R2048b_0, R_0_R2048b_1, R_0_R2048b_0 P_256B_STORE_DWORD pword ptr [rip + a], R_0_R2048b_0 I added the following lines in X86MCInstLower.cpp; unsigned NewOpc; switch (OutMI.getOpcode())

Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: 2008-09-19/xen/arch/x86/platform_hypercall.c =================================================================== --- 2008-09-19.orig/xen/arch/x86/platform_hypercall.c 2008-09-19 14:12:02.000000000 +0200 +++ 2008-09-19/xen/arch/x86/platform_hypercall.c 2008-09-19 14:12:56.000000000 +0200 @@ -21,7 +21,7 @@ #include <xen/acpi.h>

This patch enables PCI passthrough with stub domain. PCI passthrough with stub domain has failed in the past. The primary reason is that hypercalls from qemu in stub domain are rejected. This patch allows qemu in stub domain to call the hypercalls which is needed for PCI passthrough. For security, if target domain of hypercall is different from that of stub domain, it rejects hypercall. To use

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 register should appear on the right and the mask should appear on the

Hi David, I'm catching up on email at the moment so I don't know if you've done this, but patches should go to llvm-commits for review if you wouldn't mind. Thanks! -eric On Thu Dec 12 2013 at 8:39:19 AM, David Woodhouse <dwmw2 at infradead.org> wrote: > This attempts to address http://llvm.org/bugs/show_bug.cgi?id=18220 > It also fixes a test which was requiring

Hello, I'm trying to understand the relationship between MachineMemOperand and, on X86, memory operands of machine instructions. The latter seem to be operands held in order by the MachineInstr, from an offset onwards - Base, Scale, Index, Displacement, Segment. The former, if I understand it correctly, is used to hold a relationship back to IR load/store instructions. Is it possible to have

Sorry, forgot to Reply-All. Begin forwarded message: > From: Steve Montgomery <stephen.montgomery3 at btinternet.com> > Subject: Re: [LLVMdev] Prevention register promotion at the isel codegen phase > Date: 24 November 2012 17:09:58 GMT > To: Joseph Pusdesris <joe at pusdesris.com> > > I had a similar problem trying to implement reg-mem operations. The solution I

Good day - This is my first post to this list , and I''m new to Xen - any help on this issue would be much appreciated . I downloaded, built and installed xen-4.2.1 (hypervisor and tools) on an x86_64 ArchLinux box updated to latest software as of today. I am trying to bring up a Linux guest from a remote iSCSI disk. The iSCSI-initiator (open-iscsi) logs in to the remote target OK and