search for: mrmsrcmem

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 MRMSrcMem in RecognizableInstr::emitInstructionSpecifier. And the above gives us $dst,...

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

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), > ... > } > There is a problem since MRMSrcMem assumes the 2nd physical operand is a memory operand. > See the section about MRMSrcMem in RecognizableInstr::emitInstructionSpecifier. Can...

...ion register should appear on the right and the mask should appear on the left as we use AT&T syntax by default. It will probably conflict with your updates here. On Mon, Jul 9, 2012 at 11:24 PM, Manman Ren <mren at apple.com> wrote: > > 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->getOpera...

...inal) > +++ llvm/trunk/lib/Target/X86/X86InstrSSE.td Thu May 26 18:13:19 2011 > @@ -4935,66 +4935,66 @@ > // This set of instructions are only rm, the only difference is the size > // of r and m. > let Constraints = "$src1 = $dst" in { > - def CRC32m8 : SS42FI<0xF0, MRMSrcMem, (outs GR32:$dst), > + def CRC32r32m8 : SS42FI<0xF0, MRMSrcMem, (outs GR32:$dst), > (ins GR32:$src1, i8mem:$src2), > "crc32{b} \t{$src2, $src1|$src1, $src2}", > [(set GR32:$dst, > -...

Thank You. Still getting errors.I have modified my instructions as you said as follows: def GATHER_256B : I<0x68, MRMSrcMem, (outs VR_2048:$dst, VK64WM:$mask_wb), (ins VR_2048:$src1, VK64WM:$mask, i2048mem:$src2), "GATHER_256B\t{$src2, {$dst} {${mask}}|${dst} {${mask}}, $src2}", [(set VR_2048:$dst, VK64WM:$mask_wb, (v64i32 (masked_gather (VR_2048:$src1), VK64WM:$mask,...

Hello, I m working towards backend. Here i need to define vector load and stores for 64 i32 elements. so in x86instrinfo.td i wrote; def VMOV_256B_RM : I<0x6F, MRMSrcMem, (outs VR2048:$dst), (ins i32mem:$src), "vmov_256B_rm\t{$src, $dst|$dst, $src}", [(set VR2048:$dst, (v64i32 (scalar_to_vector (loadi32 addr:$src))))], IIC_MOV_MEM>, EVEX; def VMOV_256B_MR : I<0x7F, MRMDestMem, (outs), (ins...

Hello, I did as you said, Please tell me whether the following correct now?? def GATHER_256B : I<0x68, MRMSrcMem, (outs VR_2048:$dst, _.KRCWM:$mask_wb), (VR_2048:$src1, _.KRCWM:$mask, ins i2048mem:$src2), "GATHER_256B\t{$src2, {$dst}{${mask}}|${dst} {${mask}}, $src2}"), [(set VR_2048:$dst, _.KRCWM:$mask_wb, (v64i32 (GatherNode (VR_2048:$src1), _.KRCWM:$mask,...

...gt; { > def rri : PIi8<0xC2, MRMSrcReg, > (outs RC:$dst), (ins RC:$src1, RC:$src2, CC:$cc), asm, > [(set RC:$dst, (Int RC:$src1, RC:$src2, imm:$cc))], > itins.rr, d>, > Sched<[WriteFAdd]>; > def rmi : PIi8<0xC2, MRMSrcMem, > (outs RC:$dst), (ins RC:$src1, x86memop:$src2, CC:$cc), asm, > [(set RC:$dst, (Int RC:$src1, (memop addr:$src2), imm:$cc))], > itins.rm, d>, > Sched<[WriteFAddLd, ReadAfterLd]>; > > // Accept explicit immediate argum...

...on. Since I just started, here are my first several questions and proposals. I hope that some of them make sense for you. 1. Why does X86 instruction set description provide different descriptions for the same instructions, which differ only in the size of operands? E.g. def MOV8rm : I<0x8A, MRMSrcMem, (ops GR8 :$dst, i8mem :$src), "mov{b} {$src, $dst|$dst, $src}", [(set GR8:$dst, (load addr:$src))]>; def MOV16rm : I<0x8B, MRMSrcMem, (ops GR16:$dst, i16mem:$src), "mov{w} {$src, $dst|$dst, $src}", [(set GR16...

Hi, in X86InstrArithmetic.td, we have LEA16r defined as: def LEA16r : I<0x8D, MRMSrcMem, (outs GR16:$dst), (ins i32mem:$src), "lea{w}\t{$src|$dst}, {$dst|$src}", [], IIC_LEA_16>, OpSize16; Please correct me if I am wrong, but I think "ins i32mem" should be "ins i16mem" because this is about 16bit register? So is thi...

i want to implement gather for v64i32. i wrote following code. def GATHER_256B : I<0x68, MRMSrcMem, (outs VR_2048:$dst), (ins i2048mem:$src), "GATHER_256B\t{$src, $dst|$dst, $src}", [(set VR_2048:$dst, (v64i32 (masked_gather addr:$src)))], IIC_MOV_MEM>, TA; def: Pat<(v64f32 (masked_gather addr:$src)), (GATHER_256B addr:$...

hi, some instructions mismatch between assembler & disassembler, like below. it seems this happens with all SSECC related instructions? thanks, Jun $ echo "cmpps xmm1, xmm2, 23" | ./Release+Asserts/bin/llvm-mc -assemble -triple=x86_64 --output-asm-variant=1 -x86-asm-syntax=intel -show-encoding .text cmpps xmm1, xmm2, 23 # encoding: [0x0f,0xc2,0xca,0x17] $

...Intrinsic<[llvm_i64_ty, llvm_v2f64_ty], [IntrNoMem]>; This matches the signature of the GCC intrinsic. The fact that the GCC intrinsic has a type mismatch on the input (vector rather than scalar) is strange, but ok, we'll run with it. Until this: def Int_CVTSD2SIrm : SDI<0x2D, MRMSrcMem, (outs GR32:$dst), (ins f128mem: $src), "cvtsd2si\t{$src, $dst|$dst, $src}", [(set GR32:$dst, (int_x86_sse2_cvtsd2si (load addr:$src)))]>; Er, this makes us load a 128-bit quantity, which is a...

...first several questions and > proposals. I hope that some of them make sense for you. Ok. > 1. Why does X86 instruction set description provide different > descriptions for the same instructions, which differ only in the size > of operands? > E.g. > > def MOV8rm : I<0x8A, MRMSrcMem, (ops GR8 :$dst, i8mem :$src), > "mov{b} {$src, $dst|$dst, $src}", > [(set GR8:$dst, (load addr:$src))]>; > def MOV16rm : I<0x8B, MRMSrcMem, (ops GR16:$dst, i16mem:$src), > "mov{w} {$src, $dst|$dst, $src}", >...

Tracking down a problem with one of our benchmark codes, we've discovered that some of the patterns in X86InstrX86-64.td are wrong. Specifically: def MOV64toPQIrm : RPDI<0x6E, MRMSrcMem, (outs VR128:$dst), (ins i64mem:$src), "mov{d|q}\t{$src, $dst|$dst, $src}", [(set VR128:$dst, (v2i64 (scalar_to_vector (loadi64 addr:$src))))]>; def MOVPQIto64mr : RPDI<0x7E, MRMDestMem, (outs), (ins i64mem:...

...k/lib/Target/X86/X86InstrFMA.td?r1=162999&r2=162998&pathrev=162999 For the multiclass "fma4s", why is "mr" not inherited from "VEX_W" and "MemOp4" like those of "rm" or "rr" ? multiclass fma4s< > ... def mr : FMA4<opc, MRMSrcMem, (outs RC:$dst), (ins RC:$src1, x86memop:$src2, RC:$src3), !strconcat(OpcodeStr, "\t{$src3, $src2, $src1, $dst|$dst, $src1, $src2, $src3}"), [(set RC:$dst, (OpNode RC:$src1, (mem_frag addr:$src2), RC:$src3))]>; ... It seems that previous re...

Hi all, I'm trying to simulate an extended x86 architecture on gem5 with several new instructions. My hardware setup is done and now I'd like llvm to accept the existence of the new instruction passed in inline assembly and output the correct opcode and registers. I chose the two-byte opcode 0x0F 0x7A and I would like the instruction to have the same operands and return values as CVTPS2PI

On Wed, Nov 7, 2012 at 10:52 PM, Anitha Boyapati <anitha.boyapati at gmail.com>wrote: ... > For the multiclass "fma4s", why is "mr" not inherited from "VEX_W" and > "MemOp4" like those of "rm" or "rr" ? > Hey Anitha, The VEX.W bit is used to denote operand order. In other words, this bit allows for a memop to be used as

...tion that has two immediates. The first is 16-bits the second one is controlled by ImmT field. MRMDestMem - modrm.mod!=0x3, modrm[2:0] and optional sib byte and displacement encode destination memory address. vex.vvvv is used encodes the next register, modrm[5:3] encodes destination register. MRMSrcMem - modrm.mod!=0x3, modrm[5:3] encodes destination register. if vex.vvvv is used it encodes the next register, modrm[2:0] encodes second or third source register MRMSrcMem4VOp3 - like MRMSrcMem, but vex.vvvv and memory operand are swapped. Rarely used. MRMSrcMemOp4 - like MRMSrcMem, but a se...