search for: i64mem

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:$dst, VR128: $src),...

...f int_x86_mpx_bndmk: Intrinsic<[llvm_x86bnd_ty], [llvm_ptr_ty, llvm_i64_ty], []>; } ``` And following instruction that is generated when @llvm.x86.mpx.bndmk is used in code: ``` let isPseudo = 1 in let usesCustomInserter = 1 in def BNDMK64rm_Int: PseudoI<(outs BNDR:$dst), (ins i64mem:$src, GR64:$shift), [(set BNDR:$dst, (int_x86_mpx_bndmk addr:$src, i64:$shift))]>; ``` Everything works completely fine, intrinsic gets matched. But if I add "IntrNoMem" attribute to instrinsic like: ``` let TargetPrefix = "x86" in { // All intrinsics start with "ll...

...Dec 12, 2007, at 2:10 PM, David Greene wrote: > 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:...

...LAGS], Uses = [EAX,EDX] in // EDX:EAX/[mem32] = EAX,EDX def DIV32m : I<0xF7, MRM6m, (outs), (ins i32mem:$src), "div{l}\t$src", [], IIC_DIV32>; // RDX:RAX/[mem64] = RAX,RDX let Defs = [RAX,RDX,EFLAGS], Uses = [RAX,RDX] in def DIV64m : RI<0xF7, MRM6m, (outs), (ins i64mem:$src), "div{q}\t$src", [], IIC_DIV64>; } It is a complete coincidence that these instructions happen to be missing neverHasSideEffects = 1 ;) Often, you can set the mayLoad flag as part of a multiclass when you define the *rm variant. X86 is the worst case because so...

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,

...in // EDX:EAX/[mem32] = EAX,EDX > def DIV32m : I<0xF7, MRM6m, (outs), (ins i32mem:$src), > "div{l}\t$src", [], IIC_DIV32>; > // RDX:RAX/[mem64] = RAX,RDX > let Defs = [RAX,RDX,EFLAGS], Uses = [RAX,RDX] in > def DIV64m : RI<0xF7, MRM6m, (outs), (ins i64mem:$src), > "div{q}\t$src", [], IIC_DIV64>; > } > > It is a complete coincidence that these instructions happen to be missing neverHasSideEffects = 1 ;) It's also a serious tblgen deficiency that we can't write patterns for these. Look at the terrible...

...(int_x86_sse42_crc32_64_8 GR64:$src1, GR8:$src2))]>, > REX_W; > - def CRC64m64 : SS42FI<0xF1, MRMSrcMem, (outs GR64:$dst), > + def CRC32r64m64 : SS42FI<0xF1, MRMSrcMem, (outs GR64:$dst), > (ins GR64:$src1, i64mem:$src2), > "crc32{q} \t{$src2, $src1|$src1, $src2}", > [(set GR64:$dst, > - (int_x86_sse42_crc64_64 GR64:$src1, > + (int_x86_sse42_crc32_64_64 GR64:$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