search for: x86inst

llvm/lib/Target/X86/X86InstrInfo.td: class X86Inst<bits<8> opcod, Format f, ImmType i, dag ops, string AsmStr> : Instruction { .... dag OperandList = ops; string AsmString = AsmStr; } def MOV32mi : Ii32<0xC7, MRM0m, (ops i32mem:$dst, i32imm:$src), "mov{l} {$src, $dst|$dst...

On Fri, 6 May 2005, Tzu-Chien Chiu wrote: > llvm/lib/Target/X86/X86InstrInfo.td: > class X86Inst<bits<8> opcod, Format f, ImmType i, dag ops, string > AsmStr> : Instruction { > .... > dag OperandList = ops; > string AsmString = AsmStr; > } > > def MOV32mi : Ii32<0xC7, MRM0m, (ops i32mem:$dst, i32imm:$src), >...

The macro $src, $dest used in Instruction::AsmString must be "declared" in Instruction::OperandList, right? $$ has special meaning? On 5/6/05, Chris Lattner <sabre at nondot.org> wrote: > On Fri, 6 May 2005, Tzu-Chien Chiu wrote: > > llvm/lib/Target/X86/X86InstrInfo.td: > > class X86Inst<bits<8> opcod, Format f, ImmType i, dag ops, string > > AsmStr> : Instruction { > > .... > > dag OperandList = ops; > > string AsmString = AsmStr; > > } > > > > def MOV32mi : Ii32<0xC7, MRM0m, (ops i...

On Mon, 14 Apr 2008, Edward Lee wrote: > On Mon, Apr 14, 2008 at 6:00 PM, Chris Lattner <sabre at nondot.org> wrote: >> You can change the code generator or not run the block layout pass. > Ok thanks for the help. I'll try finding where to twiddle this. > Perhaps explicitly check if the branch's condition is the call to my > intrinsic. > > Or is there another

On Mon, Apr 14, 2008 at 5:02 PM, Bill Wendling <isanbard at gmail.com> wrote: > Then that flow would be explicit in the CFG, right? Then %F wouldn't > be dead, I'm assuming. Right. That's why I used a conditional branch after the intrinsic, but it sounds like the CFG simplification pass after lowering will optimize it away and no longer have the flow explicit. (To the

Copy Ii32 in X86InstrFormats.td rename to Ii64 and change Imm32 to Imm64. Instantiate your instruction inheriting from Ii64. Pass RawFrm to the form parameter. Initial documentation for the encoding system is attached. ~Craig On Wed, Mar 28, 2018 at 4:50 PM, Gus Smith via llvm-dev < llvm-dev at lists.llvm.org>...

...Target/X86 because when I did, I received a tablegen error. I think I'm not understanding the difference between an intrinsic that maps directly to a single machine instruction, and a more complex intrinsic that invokes a C function. In particular, I tried adding: def int_test_and_clear_bit : X86Inst; to the end of X86.td, but that resulted in a tablegen compilation error. Code I've added to the end of LowerIntrinsicCall in /lib/CodeGen/IntrinsicLowering.cpp: ----------------- case Intrinsic::test_intrinsic: break; ----------------- Note that the intent is to make this intrinsic...

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

Hal, that’s a good point. There are more manually-maintained tables in the X86 backend that should probably be tablegened: the memory-folding tables and ReplaceableInstrs, to name a couple. If you have ideas on how to get these auto-generated, please let us know. From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Hal Finkel via llvm-dev Sent: Wednesday, November 23, 2016