similar to: [LLVMdev] TableGen !eq() Operator Patch

Displaying 20 results from an estimated 40000 matches similar to: "[LLVMdev] TableGen !eq() Operator Patch"

2010 Jan 05
0
[LLVMdev] TableGen !eq() Operator Patch
On Jan 5, 2010, at 9:59 AM, David Greene wrote: > Attached is a patch to implement an !eq() operator in TableGen. We > use this > for the AVX specification to allow the user to control what kind of > pattern > should be used for a particular instruction def. For example, we > use it for > reg-mem instructions to let the user choose between a built-in > generic
2010 Aug 30
1
[LLVMdev] Recursion in TableGen
I've been playing around with some ways to tighted up our AVX specification and have hit upon a nice way to reduce a bunch of code. Unfortunately, right now TableGen can't handle it. Here's a simple example of what I want to do: class Data<string n, int v> { string Name = n; int Value = v; } // Define some objects usable as arguments. def X : Data<"X", 1>;
2011 Sep 22
0
[LLVMdev] Patch to synthesize x86 hadd instructions; need help with the tablegen bits
The output of the avx-hadd program is 3 11 7 15 Preston -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Duncan Sands Sent: Thursday, September 22, 2011 3:14 PM To: Bruno Cardoso Lopes Cc: LLVMdev Subject: Re: [LLVMdev] Patch to synthesize x86 hadd instructions; need help with the tablegen bits Hi Bruno, > Some comments:
2011 Sep 21
2
[LLVMdev] Patch to synthesize x86 hadd instructions; need help with the tablegen bits
This patch synthesizes haddps/haddpd/hsubps/hsubpd instructions from floating point additions and subtractions of appropriate vector shuffles. To do this I introduced new x86 FHADD and FHSUB opcodes. These need to be wired up somehow in the .td file to the appropriate instructions. Since I have no idea how tablegen works I just hacked it in horribly. It works, but breaks support for the hadd
2011 Sep 22
3
[LLVMdev] Patch to synthesize x86 hadd instructions; need help with the tablegen bits
Hi Bruno, > Some comments: > > + // Try to synthesize horizontal adds from adds of shuffles. > + if (((Subtarget->hasSSE3()&& (VT == MVT::v4f32 || VT == MVT::v2f64)) || > + (Subtarget->hasAVX()&& (VT == MVT::v8f32 || VT == MVT::v4f64)))&& > + isHorizontalBinOp(LHS, RHS, true)) > > 1) You probably want to do something like: >
2011 Sep 21
0
[LLVMdev] Patch to synthesize x86 hadd instructions; need help with the tablegen bits
Hi Duncan, On Wed, Sep 21, 2011 at 1:24 PM, Duncan Sands <baldrick at free.fr> wrote: > This patch synthesizes haddps/haddpd/hsubps/hsubpd instructions from > floating > point additions and subtractions of appropriate vector shuffles.  To do this > I > introduced new x86 FHADD and FHSUB opcodes.  These need to be wired up > somehow > in the .td file to the appropriate
2020 Nov 16
2
Occasional TableGen Newsletter, no. 2
This is the second in a series of occasional TableGen newsletters. The purpose is to inform the greater LLVM community of changes and enhancements to TableGen and its backends. * As announced previously, there are two new TableGen documents and three updated ones: TableGen Overview --- https://llvm.org/docs/TableGen/ TableGen Programmer's Reference ---
2012 Mar 23
0
[LLVMdev] tablegen question
>From my understanding, NAME is a special builtin entry and dedicated for things related multiclass, So, is the following rewrite what you want? class Base<int V> { int Value = V; } class Derived<string Truth> : Base<!if(!eq(Truth, "true"), 1, 0)>; multiclass Derived_m<string T> { def #NAME# : Derived<T>; } defm TRUE :
2012 Mar 16
2
[LLVMdev] tablegen question
Trying to resolve some general tablegen questions. Consider the test case for Tablegen called eq.td class Base<int V> { int Value = V; } class Derived<string Truth> : Base<!if(!eq(Truth, "true"), 1, 0)>; def TRUE : Derived<"true">; def FALSE : Derived<"false">; If I process this through tablegen I get: ------------- Classes
2012 Mar 24
2
[LLVMdev] tablegen question
According to the TableGen manual: "Each def record has a special entry called "NAME." This is the name of the def ("ADD32rr" above). In the general case def names can be formed from various kinds of string processing expressions and NAME resolves to the final value obtained after resolving all of those expressions. The user may refer to NAME anywhere she desires to
2009 Jun 04
2
[LLVMdev] TableGen Type Inference
Can someone explain why TableGen can't figure this out? VCVTDQ2PS128rm: (set:isVoid VR128:v4f32:$dst, (sint_to_fp:v4f32 (bitconvert:isInt (ld:v4i32 addr:iPTR:$src)<<P:Predicate_memop>>))) llvm/tblgen: In VCVTDQ2PS128rm: Could not infer all types in pattern! The pattern as written looks like this: [(set VR128:$dst, (v4f32 (sint_to_fp (bc_memopv4i32 addr:$src))))] I'm
2012 Aug 06
2
[LLVMdev] Tablegen foreach
I'm trying to find examples of the foreach pattern being used in tablegen files. The problem I am trying to solve is to simplify the amount of tablegen code I have to produce because each operand of an instruction can be a register or a literal. So for binary, we have 4 instructions, ternary, 8, and quaternary 16 combinations. Instead of writing all the combinations out, I'd like to use
2012 Aug 06
0
[LLVMdev] Tablegen foreach
I think a multiclass may be a better fit for what you are trying to do. In fact, this is the canonical example for multiclasses: <http://llvm.org/docs/TableGenFundamentals.html#multiclass-definitions-and-instances>. --Sean Silva On Mon, Aug 6, 2012 at 1:55 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > I’m trying to find examples of the foreach pattern being used in
2017 Sep 25
1
TableGen questions.
Hello all, I have two Tablegen questions in the context of an unconventional architecture. The pertinent details: the architecture has multiple register files that are selected via a bit in the instruction. One of the register files is a traditional one. The other is unconventional in that all source and dest registers are both read from and written to by the instructions. So add special0,
2012 Aug 06
2
[LLVMdev] Tablegen foreach
That is what I currently have, I'm trying to simplify them even further since my multiclass file is enormous because of the amount of combinations. I have things like this: multiclass instmcRegImm<...> { def rr: inst<...>; def ri: inst<...>; def ir: inst<...>; def ii: inst<...>; } multiclass instmc<...> { defm i8 : instmcRegImm<...>; ^-- repeat for 15
2012 Dec 11
0
[LLVMdev] FW: Register classes, reg unit weights calculation in tablegen
To: Andrew Trick Hi, I write you directly as you are the commiter of the code I am having problems with for my target - see below. I wonder what you think about this? Thanks, Jonas ________________________________ From: Jonas Paulsson Sent: Thursday, December 06, 2012 4:14 PM To: llvmdev at cs.uiuc.edu Subject: Register classes, reg unit weights calculation in tablegen Hi, I have a problem
2012 Aug 06
0
[LLVMdev] Tablegen foreach
I believe multiclasses can be nested. Could that help you reduce the duplication? --Sean Silva On Mon, Aug 6, 2012 at 2:46 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > That is what I currently have, I'm trying to simplify them even further since my multiclass file is enormous because of the amount of combinations. I have things like this: > > multiclass
2012 Dec 06
0
[LLVMdev] Register classes, reg unit weights calculation in tablegen
Hi, I have a problem with the assert in Tablegen: llvm-tblgen: /dev/shm/uabpath/dev-master/utils/TableGen/RegisterInfoEmitter.cpp:204: void <anonymous namespace>::RegisterInfoEmitter::EmitRegUnitPressure(llvm::raw_ostream &, const llvm::CodeGenRegBank &, const std::string &): Assertion `RU.Weight < 256 && "RegUnit too heavy"' failed. The reason for
2008 Oct 24
2
[LLVMdev] SetCC tablegen pattern
I am attempting to match setcc using tablegen w/ the following patterns: def FEQ : Instruction<(outs GPRF32:$dst), (ins GPRF32:$src0, GPRF32:$src1), "eq $dst, $src0, $src1", [(set GPRF32:$dst, (seteq GPRF32:$src0, GPRF32:$src1))]>; And it is failing stating that the result must be an integer. Is there a way around this other than modifying TargetSelectionDAG.td? Also,
2009 Dec 16
2
[LLVMdev] Early-clobber constraint in TableGen
On Dec 15, 2009, at 5:08 PM, David Greene wrote: > On Tuesday 15 December 2009 18:01, Jim Grosbach wrote: > >> For a usage example, I've included in the patch the modification to >> use the constraint for the STREX ARM instruction. > > Your example is: > > constraints = "@early $success" > > Why not spell it as: > > constraints =