search for: i8mem

...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:$dst, (load addr:$src)...

...6. Thanks. diff --git a/lib/Target/X86/X86InstrInfo.td b/lib/Target/X86/X86InstrInfo.td index e9a0431..f5b2064 100644 --- a/lib/Target/X86/X86InstrInfo.td +++ b/lib/Target/X86/X86InstrInfo.td @@ -1412,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),...

...> 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}", > [(set GR16:$...

Here's a couple examples for mapping an intrinsic to an X86 instruction from X86InstrInfo.td. If you look for int_x86_* in any X86Instr*.td you can find others. let Predicates = [HasCLFLUSHOPT], SchedRW = [WriteLoad] in def CLFLUSHOPT : I<0xAE, MRM7m, (outs), (ins i8mem:$src), "clflushopt\t$src", [(int_x86_clflushopt addr:$src)], IIC_SSE_PREFETCH>, PD; let Predicates = [HasCLWB], SchedRW = [WriteLoad] in def CLWB : I<0xAE, MRM6m, (outs), (ins i8mem:$src), "clwb\t$src", [(int_...

...t; Here's a couple examples for mapping an intrinsic to an X86 instruction > from X86InstrInfo.td. If you look for int_x86_* in any X86Instr*.td you can > find others. > > let Predicates = [HasCLFLUSHOPT], SchedRW = [WriteLoad] in > def CLFLUSHOPT : I<0xAE, MRM7m, (outs), (ins i8mem:$src), > "clflushopt\t$src", [(int_x86_clflushopt addr:$src)], > IIC_SSE_PREFETCH>, PD; > > let Predicates = [HasCLWB], SchedRW = [WriteLoad] in > def CLWB : I<0xAE, MRM6m, (outs), (ins i8mem:$src), "clwb\t$src", &...

Hello all. LLVM newbie here. If anything seems glaringly wrong with my use of LLVM, that's probably why. Here's what I'm trying to do. I have modified the gem5 simulator to accept a "new" x86 instruction. I've done this by just reserving the opcode in gem5's ISA specification, just as all other instructions are specified. I'm trying to get an LLVM backend to

...le examples for mapping an intrinsic to an X86 instruction >> from X86InstrInfo.td. If you look for int_x86_* in any X86Instr*.td you can >> find others. >> >> let Predicates = [HasCLFLUSHOPT], SchedRW = [WriteLoad] in >> def CLFLUSHOPT : I<0xAE, MRM7m, (outs), (ins i8mem:$src), >> "clflushopt\t$src", [(int_x86_clflushopt addr:$src)], >> IIC_SSE_PREFETCH>, PD; >> >> let Predicates = [HasCLWB], SchedRW = [WriteLoad] in >> def CLWB : I<0xAE, MRM6m, (outs), (ins i8mem:$src), &quot...

...lot for your answer! Chris Lattner wrote: >> 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}", >>...

...ing an intrinsic to an X86 instruction >>> from X86InstrInfo.td. If you look for int_x86_* in any X86Instr*.td you can >>> find others. >>> >>> let Predicates = [HasCLFLUSHOPT], SchedRW = [WriteLoad] in >>> def CLFLUSHOPT : I<0xAE, MRM7m, (outs), (ins i8mem:$src), >>> "clflushopt\t$src", [(int_x86_clflushopt addr:$src)], >>> IIC_SSE_PREFETCH>, PD; >>> >>> let Predicates = [HasCLWB], SchedRW = [WriteLoad] in >>> def CLWB : I<0xAE, MRM6m, (outs), (in...

...like the follow to X86.td: def IsIntelAsmWriter : Predicate<"Subtarget.isFlavorIntel()">; def IsATTAsmWriter : Predicate<"!Subtarget.isFlavorIntel()">; and then in X86InstrInfo.td make changes something like: def SHL8mCLIntel : I<0xD2, MRM4m, (outs), (ins i8mem :$dst), "shl{b}\t{%cl, $dst|$dst, CL}", [(store (shl (loadi8 addr:$dst), CL), addr:$dst)]>, requires<[IsIntelAsmWriter]>; def SHL8mCLATT : I<0xD2, MRM4m, (outs), (ins i8mem :$dst), "shl{b}\t{%cl, $dst|$dst, %CL}", [(store (shl (loadi8...

On Mon, Jun 15, 2009 at 5:49 PM, Gaster, Benedict<Benedict.Gaster at amd.com> wrote: > I would like to use the LLVM x86 code generator to emit Intel syntax that is > compatible with Microsoft’s MASM 9.x. Taking the TOT LLVM, from last week, I > have found a number of changes that are required to make this work, most of > which are straight forward but a couple I wanted to check

I would like to use the LLVM x86 code generator to emit Intel syntax that is compatible with Microsoft's MASM 9.x. Taking the TOT LLVM, from last week, I have found a number of changes that are required to make this work, most of which are straight forward but a couple I wanted to check with the group to see what people thought was the best thing to do. In particular, I have made all necessary

...re 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, > - (int_x86_sse42_crc32_8 GR32:$src1, > + (int_x86_sse42_crc32_32_8 GR32:$src1, > (l...

If I have an instruction which has many register and immediate operands, what's the difference between these two implementations to define the instruction in TableGen *.td file? (1) Similar to what has been done to complex X86 addressing mode. A single 32-bit immediate (i32) encodes how to add many MachineOperands to the MachineInstr object (With the help of functions in X86InstrBuilder.h).

...nd we could accurately infer properties, it wouldn't be a problem. > Won't this hugely bloat the .td files? Not really, TableGen has a fairly convenient syntax for bulk flagging: 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...

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,

...td > b/lib/Target/X86/X86InstrInfo.td > > index e9a0431..f5b2064 100644 > > --- a/lib/Target/X86/X86InstrInfo.td > > +++ b/lib/Target/X86/X86InstrInfo.td > > @@ -1412,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,...

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

...that expand to a single instruction? >> Won't this hugely bloat the .td files? > > Not really, TableGen has a fairly convenient syntax for bulk flagging: > > 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>,...

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