search for: mrm6m

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) ? (MI.getOperand(CurOp+4).isImm() ? X86InstrInfo::size...

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]>; > > In X86CodeEmitter.cpp in emitInstruction > > case X86II::MRM6m: case X86II::MRM7m: { > intptr_t PCAdj = (CurOp+4 != NumOps) ? > (MI.getOperand(CurO...

...nce 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]>; >> >> In X86CodeEmitter.cpp in emitInstruction >> >> case X86II::MRM6m: case X86II::MRM7m: { >> intptr_t PCAdj = (CurOp+4 != NumOps) ? >...

...ions had patterns, and 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&gt...

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,

...s from Pat patterns 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"...

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

...T], 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_x86_clwb addr:$src)], IIC_SSE_PREFETCH>, PD; The encoding information for the binary output is buried in these definitions too. If you tell me what opcode you've chosen I can tell you what the right things are to ge...

...> 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_x86_clwb addr:$src)], IIC_SSE_PREFETCH>, PD; > > The encoding information for the binary output is buried in these > definitions too. If you tell me what opcode you've chosen I can tell you > what th...

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

...: 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_x86_clwb addr:$src)], IIC_SSE_PREFETCH>, PD; >> >> The encoding information for the binary output is buried in these >> definitions too. If you tell me what opcode you've chosen I can tell...

...Reg(MO)) > - REX |= 1 << Bit; > - Bit++; > - } > - } > - break; > - } > - case X86II::MRM0m: case X86II::MRM1m: > - case X86II::MRM2m: case X86II::MRM3m: > - case X86II::MRM4m: case X86II::MRM5m: > - case X86II::MRM6m: case X86II::MRM7m: > - case X86II::MRMDestMem: { > - unsigned e = isTwoAddr ? 5 : 4; > - i = isTwoAddr ? 1 : 0; > - if (NumOps > e && isX86_64ExtendedReg(MI.getOperand(e))) > - REX |= 1 << 2; > - unsigned Bit = 0; > - for (;...

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

...(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_x86_clwb addr:$src)], IIC_SSE_PREFETCH>, PD; >>> >>> The encoding information for the binary output is buried in these >>> definitions too. If you tell me what opcode you've ch...