similar to: [LLVMdev] TSFlagsFields and TSFlagsShifts obsolete?

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

Hi, I noticed, that execution domain is set to SSEPackedSingle for these instructions. Looks like a bug. let neverHasSideEffects = 1, ExeDomain = SSEPackedSingle in { def VEXTRACTF128rr : AVXAIi8<0x19, MRMDestReg, (outs VR128:$dst), - Elena --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain

What domain do you think they should have? They are floating point, but not technically double or single. The domain fix pass will treat them as either anyway as I've put them in the table for both single and double. >From X86InstrInfo.cpp { X86::VEXTRACTF128mr, X86::VEXTRACTF128mr, X86::VEXTRACTI128mr }, { X86::VEXTRACTF128rr, X86::VEXTRACTF128rr, X86::VEXTRACTI128rr }, {

I think that it should not belong to any domain. And I see a problem with this table. If you run in AVX mode and call lookup with VEXTRACTF128rr you fail with assertion. - Elena From: Craig Topper [mailto:craig.topper at gmail.com] Sent: Wednesday, January 04, 2012 19:32 To: Demikhovsky, Elena Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Execution domain for VEXTRACTF128/VINSERTF128 What

On Mon, 7 Jun 2004, Vladimir Prus wrote: > > Hello, > I'm trying to write assembler code writer, and of course, have new questions. > I'd like the structure my implementation like this: > if (/*binary instruction*/) { > if (/* unary instruction */ ) { > if (/*control instruction*/) { Okay, that should be no problem. > The question is how to write those

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, I'm trying to write assembler code writer, and of course, have new questions. I'd like the structure my implementation like this: if (/*binary instruction*/) { // print destination O << " = "; // print first operand O << opcode; // print second operand. } if (/* unary instruction */ ) { .... } if (/*control instruction*/) { ....

Hello, I did as you said, Please tell me whether the following correct now?? def GATHER_256B : I<0x68, MRMSrcMem, (outs VR_2048:$dst, _.KRCWM:$mask_wb), (VR_2048:$src1, _.KRCWM:$mask, ins i2048mem:$src2), "GATHER_256B\t{$src2, {$dst}{${mask}}|${dst} {${mask}}, $src2}"), [(set VR_2048:$dst, _.KRCWM:$mask_wb, (v64i32 (GatherNode

Craig, thanks for the quick response. That helps a lot. I had no clue they were buried in there, 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

Thank You. Still getting errors.I have modified my instructions as you said as follows: def GATHER_256B : I<0x68, MRMSrcMem, (outs VR_2048:$dst, VK64WM:$mask_wb), (ins VR_2048:$src1, VK64WM:$mask, i2048mem:$src2), "GATHER_256B\t{$src2, {$dst} {${mask}}|${dst} {${mask}}, $src2}", [(set VR_2048:$dst, VK64WM:$mask_wb, (v64i32 (masked_gather

ASM is the text output you want printed in a textual listing of the assembly. The curly braces you see in some text strings like "adcx{l}\t{$src, $dst|$dst, $src}" are there to provide different operand orders for at&t syntax vs intel syntax. Anything after $ matches the name in the outs/in part of the instruction. IIC_SSE_PREFETCH is part of the scheduler system to provide

Hi all, I'm trying to simulate an extended x86 architecture on gem5 with several new instructions. My hardware setup is done and now I'd like llvm to accept the existence of the new instruction passed in inline assembly and output the correct opcode and registers. I chose the two-byte opcode 0x0F 0x7A and I would like the instruction to have the same operands and return values as CVTPS2PI

Great info -- all of this has been incredibly useful. Do you have any links to the documentation from this, or does it just come from your experiential knowledge? FYI, I achieved what I set out to achieve when I wrote this email. I'm moving on to a more complex goal now, but the original question was answered completely, in my opinion. This was the key line: def CACHEOP : I<0x06, RawFrm,

Dear all, I would like to classify all target specific instructions in a set of categories. The category of each instruction would then be available in the backend. Just to illustrate what I am trying to do, the first thing I thought about how to achieve this was to group instruction definitions in InstrInfo.td in the order of categories, and to put pseudo instructions in between to mark category

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

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, $src}">; I cannot find any document on initializing the

i want to implement gather for v64i32. i wrote following code. def GATHER_256B : I<0x68, MRMSrcMem, (outs VR_2048:$dst), (ins i2048mem:$src), "GATHER_256B\t{$src, $dst|$dst, $src}", [(set VR_2048:$dst, (v64i32 (masked_gather addr:$src)))], IIC_MOV_MEM>, TA; def: Pat<(v64f32 (masked_gather addr:$src)), (GATHER_256B

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), > "mov{l}

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 > >

On 7/10/2015 10:23 AM, Sky Flyer wrote: > Many thanks for your prompt reply. > > I mean, imagine you have 3 bits for condition flags in your instruction > (e.g. overflow, zero, carry set, ...) for conditional executions AND > there is no direct access to the Status Register, is it even possible to > implement such scenario? > There doesn't have to be any explicit status