similar to: [LLVMdev] [PATCH] fix outs/ins of MOV16mr instruction (X86)

On Wed, Mar 25, 2015 at 12:56 AM, Ahmed Bougacha <ahmed.bougacha at gmail.com> wrote: > On Tue, Mar 24, 2015 at 7:54 AM, Jun Koi <junkoi2004 at gmail.com> wrote: > > Hi, > > > > This patch fixes outs/ins of MOV16mr instruction of X86. > > > > Thanks. > > > > > > diff --git a/lib/Target/X86/X86InstrInfo.td >

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))))],

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

hello, i need to use v32i32 and v32f32 in store instructions. I defined my register as; def VRR128 : RegisterClass<"X86", [v32i32, v32f32], 1024, (add R_0_V_0, R_1_V_0, R_2_V_0)>; def STORE_DWORD : I<0x70, MRMDestMem, (outs), (ins i2048mem:$dst, VRR128:$src), "STORE_DWORD\t{$src, $dst|$dst, $src}",

Thank You. How to do the same for add please see the following; it gives duplication error. def VADD : I<0x0E, MRMDestReg, (outs VRR128:$dst), (ins VRR128:$src1, VRR128:$src2),"VADD\t{$src1, $src2, $dst|$dst, $src1, $src2}", [(set VRR128:$dst, (add VRR128:$src1, VRR128:$src2))]>, TA; def : Pat<(add VRR128:$src1, VRR128:$src2), (VADD VRPIM128:$src1, VRPIM128:$src2)>;

Thank You. But can we use same register class for fadd as well, is this instruction correct? def VFADD : I<0x0E, MRMDestReg, (outs VRR128:$dst), (ins VRR128:$src1, VRR128:$src2),"VFADD\t{$src1, $src2, $dst|$dst, $src1, $src2}", [(set VRR128:$dst, (fadd VRR128:$src1, VRR128:$src2))]>, TA; On Tue, Jul 11, 2017 at 9:00 PM, Craig Topper <craig.topper at gmail.com> wrote: >

On Wed, Mar 25, 2015 at 10:28 AM, Tim Northover <t.p.northover at gmail.com> wrote: > >> Why? i16mem here stands for the pointer, not the actual memory. A > >> store doesn't define a pointer, so why would it be in "outs"? > > > > Then why does this "i16mem:$dst" belongs to "ins"? Is that wrong, > correct? > > Think

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

Thank You. I have seen the opcode is 8 bits and all the combinations are already used in llvm x86. Now what to do? On Sat, Jul 8, 2017 at 10:57 AM, Craig Topper <craig.topper at gmail.com> wrote: > Yes its an opcode conflict. You'll have to look through Intel documents > and find an unused opcode. I've only added instructions based on a real > spec so I don't know

Thank you. i understood how avx512 vector instructions are written in x86instravx512. i need to define my vector instructions so 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))))],

Thank you; i have changed as follows.is it fine now? def VADD_256B : I<0xFE, MRMDestReg, (outs VR2048:$dst), (ins VR2048:$src1, VR2048:$src2), "VADD_256B\t{$src, $dst|$dst, $src}", [(set VR2048:$dst, (add VR2048:$src1, VR2048:$src2))]]>; Also here i have changed class RI to I. Does it make any difference? On Sat, Jul 8, 2017 at 9:38 AM, Craig Topper

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

Hi, I'm trying to implement a new backend for an embedded CISC processor. Therefore I thought that it makes sense to take X86 target as a basis, to save some time. But when I look into the X86InstrInfo.td, I have a very strong feeling that it is one of the most complex instruction set descriptions compared to other targets. I can imagine that this is due to the complexity of X86's

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

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

On Wed, Jul 10, 2013 at 12:29 PM, Ramkumar Ramachandra <artagnon at gmail.com> wrote: > The instructions btr and bts are perfectly valid, and have existed since > Intel 386. GNU as supports them fine. Unfortunately, LLVM does not > support them, and barfs with: > > error: ambiguous instructions require an explicit suffix > > Fix this problem by disambiguating it

Hi, I'm trying to add the xadd instruction to the X86 back end. xadd r/m32, r32 exchanges r/m32 and r32, and loads the sum into r/m32. I'm interested in the case where the destination operand is a memory location. I've added the following entry to X86InstrInfo.td: def XADD32mr : I<0x87, MRMDestMem, (ops i32mem:$src1, R32:$src2), "xadd{l}

On Feb 15, 2010, at 1:04 PM, David Greene wrote: >> FWIW, this is because you broke the encoding of an instruction in your >> patch. This is incorrect: >> >> +def MOVNTDQ_64mr : PSI<0xE7, MRMDestMem, (outs), (ins f128mem:$dst, >> VR128:$src), + "movntdq\t{$src, $dst|$dst, $src}", >> + [(alignednontemporalstore

On Sun, 1 Oct 2006, Roman Levenstein wrote: > I'm trying to implement a new backend for an embedded CISC processor. > Therefore I thought that it makes sense to take X86 target as a basis, > to save some time. Ok. Note that the X86 backend is one of the most complex though, because it supports several subtargets and ABIs, which makes it more complex than some other targets. >

Hi, With objdump, i have this (Intel syntax) 64 a1 00 00 00 00 mov eax,fs:0x0 However, if I pass above string to llvm-mc, I would have: $ echo "0x64 0xa1 0x00 0x00 0x00 0x00"|./Release+Asserts/bin/llvm-mc -disassemble -arch=x86 --output-asm-variant=1 .text mov eax, dword ptr [0] You can see a big difference. This is on the latest code. Any idea how to