search for: x86instrformats

On Monday 30 March 2009 16:12, David Greene wrote: > There is some redundancy at the instruction format level in the x86 .td > files. For example, in X86InstrFormats.td: > > // SSE1 Instruction Templates: > // > // SSI - SSE1 instructions with XS prefix. > > class SSI<bits<8> o, Format F, dag outs, dag ins, string asm, list<dag> > pattern> > > : I<o, F, outs, ins, asm, pattern>, XS, Requires<[HasSS...

There is some redundancy at the instruction format level in the x86 .td files. For example, in X86InstrFormats.td: // SSE1 Instruction Templates: // // SSI - SSE1 instructions with XS prefix. class SSI<bits<8> o, Format F, dag outs, dag ins, string asm, list<dag> pattern> : I<o, F, outs, ins, asm, pattern>, XS, Requires<[HasSSE1]>; // SSE3 Instruction Templates:...

hi, i am struggling to understand how MRMDestReg is used in X86. in X86InstrFormat.td, we have this: class Format<bits<7> val> { bits<7> Value = val; } def MRMDestReg : Format<3> i think eventually, MRMDestReg is mapped back to ModMRM byte. but this still doesnt make sense to me why MRMDestReg is defined this way, and how it is mapped back to ModRM byte. any hint

On Mar 30, 2009, at 2:53 PM, David Greene wrote: > On Monday 30 March 2009 16:12, David Greene wrote: >> There is some redundancy at the instruction format level in the >> x86 .td >> files. For example, in X86InstrFormats.td: >> >> // SSE1 Instruction Templates: >> // >> // SSI - SSE1 instructions with XS prefix. >> >> class SSI<bits<8> o, Format F, dag outs, dag ins, string asm, >> list<dag> >> pattern> >> >> : I<o, F, outs,...

On Tuesday 31 March 2009 13:53, Dan Gohman wrote: > > class SSI<bits<8> o, Format F, dag outs, dag ins, string asm, > > list<dag> pattern> > > > > : SSIb<o, F, outs, ins, asm, pattern>, Requires<HasSSE1>; > > Is this just factoring out the ", XS" part? As presented, it looks like > this change would introduce more

On Mar 23, 2009, at 12:57 PM, David A. Greene wrote: > I'm looking at the instruction formats and I can't grok the > comments. For > example: > > // SSSE3 Instruction Templates: > // > // SS38I - SSSE3 instructions with T8 prefix. > // SS3AI - SSSE3 instructions with TA prefix. > // > > Where are these prefix names coming from? I can't find any

I'm looking at the instruction formats and I can't grok the comments. For example: // SSSE3 Instruction Templates: // // SS38I - SSSE3 instructions with T8 prefix. // SS3AI - SSSE3 instructions with TA prefix. // Where are these prefix names coming from? I can't find any mention of them in the Intel literature. Also, there's this curious table: // Prefix byte classes

...re, though I guess I should have looked harder -- the hex should have given me a clue, perhaps! For the sake of my own edification (and not taking up too much of your time) I will try to generate it myself. I've found the definition of the "I" class at line 358 of llvm/lib/Target/X86/X86InstrFormats.td, which helps a lot. Let's assume I want to produce opcode 0x16 (which I'm using because it doesn't seem to be implemented in gem5 otherwise, and would simply produce a warning). Then my guess is that I should use something like: def CACHEADD : I<0x16, FORMAT, (outs), (ins),...

When I setup my InstrFormat fields, I added some custom fields specific for my backend. How do I access these from inside LLVM? For example: class InstrFormat<dag outs, dag ins, string asmstr, list<dag> pattern> : Instruction { let Namespace = "AMD"; dag OutOperandList = outs; dag InOperandList = ins; let Pattern = pattern; let

I am sorry, I actually meant Machine Instructions - is there a way ? One use of that is I would like to be able to group instructions together and be able check their group quickly. thanks shrey On Sun, Aug 14, 2011 at 1:16 AM, Bill Wendling <wendling at apple.com> wrote: > On Aug 13, 2011, at 11:04 AM, shreyas krishnan wrote: > >> Hi >>    Is there a way to associate

...uld have looked harder -- the hex > should have given me a clue, perhaps! > > For the sake of my own edification (and not taking up too much of your > time) I will try to generate it myself. I've found the definition of the > "I" class at line 358 of llvm/lib/Target/X86/X86InstrFormats.td, which > helps a lot. > > Let's assume I want to produce opcode 0x16 (which I'm using because it > doesn't seem to be implemented in gem5 otherwise, and would simply produce > a warning). Then my guess is that I should use something like: > def CACHEADD : I<0x16,...

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> wrote:...

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

...er -- >> the hex should have given me a clue, perhaps! >> >> For the sake of my own edification (and not taking up too much of your >> time) I will try to generate it myself. I've found the definition of the >> "I" class at line 358 of llvm/lib/Target/X86/X86InstrFormats.td, which >> helps a lot. >> >> Let's assume I want to produce opcode 0x16 (which I'm using because it >> doesn't seem to be implemented in gem5 otherwise, and would simply produce >> a warning). Then my guess is that I should use something like: >> d...

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)],

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

...MRMSrcReg, (outs FR32:$dst), (ins FR32:$src1, FR32:$src2), !strconcat(OpcodeStr, "ss\t{$src2, $dst|$dst, $src2}"), [(set FR32:$dst, (OpNode FR32:$src1, FR32:$src2))]> { let isCommutable = Commutable; } >From X86InstrFormats.td: class SSI<bits<8> o, Format F, dag outs, dag ins, string asm, list<dag> pattern> : I<o, F, outs, ins, asm, pattern>, XS, Requires<[HasSSE1]>; For AVX we would need a different set of format classes because while AVX could reuse the existing XS c...