search for: i16mem

...,7 +1412,7 @@ let SchedRW = [WriteStore] in { def MOV8mr : I<0x88, MRMDestMem, (outs), (ins i8mem :$dst, GR8 :$src), "mov{b}\t{$src, $dst|$dst, $src}", [(store GR8:$src, addr:$dst)], IIC_MOV_MEM>; -def MOV16mr : I<0x89, MRMDestMem, (outs), (ins i16mem:$dst, GR16:$src), +def MOV16mr : I<0x89, MRMDestMem, (outs i16mem:$dst), (ins GR16:$src), "mov{w}\t{$src, $dst|$dst, $src}", [(store GR16:$src, addr:$dst)], IIC_MOV_MEM>, OpSize16; def MOV32mr : I<0x89, MRMDestMem, (outs), (ins i32mem:$dst, GR32...

...in { > > def MOV8mr : I<0x88, MRMDestMem, (outs), (ins i8mem :$dst, GR8 :$src), > > "mov{b}\t{$src, $dst|$dst, $src}", > > [(store GR8:$src, addr:$dst)], IIC_MOV_MEM>; > > -def MOV16mr : I<0x89, MRMDestMem, (outs), (ins i16mem:$dst, GR16:$src), > > +def MOV16mr : I<0x89, MRMDestMem, (outs i16mem:$dst), (ins GR16:$src), > > "mov{w}\t{$src, $dst|$dst, $src}", > > [(store GR16:$src, addr:$dst)], IIC_MOV_MEM>, OpSize16; > > Why? i16mem here stands for...

...me 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:$dst, (load addr:$src))]>, OpSize; def MOV32rm : I<0x8B, MRMSrcMem, (ops GR32:$dst, i32mem:$src), "mov{l} {$src, $dst|$dst, $src}", [(set GR32:$dst, (load ad...

...AAM8i8 10)>; > // Disambiguate the mem/imm form of bt-without-a-suffix as btl. > def : InstAlias<"bt $imm, $mem", (BT32mi8 i32mem:$mem, i32i8imm:$imm)>; > > +// Disambiguate btr and bts, just like GNU as. > +def : InstAlias<"btr $imm, $mem", (BT16mi8 i16mem:$mem, i16i8imm:$imm)>; > +def : InstAlias<"bts $imm, $mem", (BT16mi8 i16mem:$mem, i16i8imm:$imm)>; > + > // clr aliases. > def : InstAlias<"clrb $reg", (XOR8rr GR8 :$reg, GR8 :$reg)>; > def : InstAlias<"clrw $reg", (XOR16rr GR16:$re...

...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 bug? Thanks, Jun -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140624/4126f408/attachment.html>

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 about a typical in...

...ly 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:$dst, (load addr:$src))]>, OpSize; > def MOV32rm : I<0x8B, MRMSrcMem, (ops GR32:$dst, i32mem:$src), > "mov{l} {$src, $dst|$dst, $src}", > [(se...

...;> // Disambiguate the mem/imm form of bt-without-a-suffix as btl. >> def : InstAlias<"bt $imm, $mem", (BT32mi8 i32mem:$mem, i32i8imm:$imm)>; >> >> +// Disambiguate btr and bts, just like GNU as. >> +def : InstAlias<"btr $imm, $mem", (BT16mi8 i16mem:$mem, i16i8imm:$imm)>; >> +def : InstAlias<"bts $imm, $mem", (BT16mi8 i16mem:$mem, i16i8imm:$imm)>; >> + >> // clr aliases. >> def : InstAlias<"clrb $reg", (XOR8rr GR8 :$reg, GR8 :$reg)>; >> def : InstAlias<"clrw $reg",...

...perands? >> 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:$dst, (load addr:$src))]>, OpSize; >> def MOV32rm : I<0x8B, MRMSrcMem, (ops GR32:$dst, i32mem:$src), >> "mov{l} {$src, $dst|$dst, $src}", >>...

...> (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? > > I think there's something going on here, but it's probably more > complicated than that. The lea instruction just calculates an address, > so the resulting pointer doesn't really *have* a size. > > Binutils seems to handl...

On Wednesday 10 July 2013 22:18:23 Jevin Sweval wrote: > http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/arch/x86/include/ > asm/bitops.h#L68 > > Here is one example that I found. Are the inline assembly arguments > ambiguous in size? It would help us for sure to build the kernel and others. -- JS

...ng: let mayLoad = 1 in { let Defs = [AL,EFLAGS,AX], Uses = [AX] in def DIV8m : I<0xF6, MRM6m, (outs), (ins i8mem:$src), // AX/[mem8] = AL,AH "div{b}\t$src", [], IIC_DIV8_MEM>; let Defs = [AX,DX,EFLAGS], Uses = [AX,DX] in def DIV16m : I<0xF7, MRM6m, (outs), (ins i16mem:$src), // DX:AX/[mem16] = AX,DX "div{w}\t$src", [], IIC_DIV16>, OpSize; let Defs = [EAX,EDX,EFLAGS], Uses = [EAX,EDX] in // EDX:EAX/[mem32] = EAX,EDX def DIV32m : I<0xF7, MRM6m, (outs), (ins i32mem:$src), "div{l}\t$src", [], IIC_DIV32>;...

I am new to the LLVM backends, I am wondering how instruction selection is done in LLVM backends, I looked at the .td files in Target/X86, they all seem to be small and do not deal with common X86 instructions, i.e. mov, push, pop, etc. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Aug 21, 2012, at 2:02 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > All, > > TableGen likes to infer the MCID::UnmodeledSideEffects flag from an instruction's pattern. When an instruction doesn't have a pattern, it is assumed to have side effects. Hi Jakob, I don't understand what you're saying. Are you proposing that all properties (may load,

On Mon, 2 Oct 2006, Roman Levenstein wrote: >>> Wouldn't it be possible and even more clean to have just one >>> description like (I use a pseudo-description here): >>> >>> def MOVrr : I<0x88, MRMDestReg, (ops (GR8|GR16|GR32) :$dst, >>> (i8mem|i16mem|i32mem):$src), >>> "mov{b} {$src, $dst|$dst, $src}", []>, > isSameSize($dst, >>> $src); >> >> We already have something like this, but it's a little more general. >> The X86 backend hasn't been converted to use it. > >...

...{ > let Defs = [AL,EFLAGS,AX], Uses = [AX] in > def DIV8m : I<0xF6, MRM6m, (outs), (ins i8mem:$src), // AX/[mem8] = AL,AH > "div{b}\t$src", [], IIC_DIV8_MEM>; > let Defs = [AX,DX,EFLAGS], Uses = [AX,DX] in > def DIV16m : I<0xF7, MRM6m, (outs), (ins i16mem:$src), // DX:AX/[mem16] = AX,DX > "div{w}\t$src", [], IIC_DIV16>, OpSize; > let Defs = [EAX,EDX,EFLAGS], Uses = [EAX,EDX] in // EDX:EAX/[mem32] = EAX,EDX > def DIV32m : I<0xF7, MRM6m, (outs), (ins i32mem:$src), > "div{l}\t$src",...

...32:$src1, GR8:$src2))]>; > - def CRC32m16 : SS42FI<0xF1, MRMSrcMem, (outs GR32:$dst), > + (int_x86_sse42_crc32_32_8 GR32:$src1, GR8:$src2))]>; > + def CRC32r32m16 : SS42FI<0xF1, MRMSrcMem, (outs GR32:$dst), > (ins GR32:$src1, i16mem:$src2), > "crc32{w} \t{$src2, $src1|$src1, $src2}", > [(set GR32:$dst, > - (int_x86_sse42_crc32_16 GR32:$src1, > + (int_x86_sse42_crc32_32_16 GR32:$src1, >...

All, TableGen likes to infer the MCID::UnmodeledSideEffects flag from an instruction's pattern. When an instruction doesn't have a pattern, it is assumed to have side effects. It's possible to override this behavior by setting neverHasSideEffects = 1. It was originally the intention that most instructions have patterns, but that's not the way it worked out. It is often more