similar to: [LLVMdev] Forward-declaring defs in TableGen

Thank you for driving this Paul, I agree that it is better to have one doc on TableGen. This has been a point of confusion for me as well - when I land in the wrong one and can’t find what I’m looking for :-). -Chris > On Jul 31, 2020, at 1:49 PM, Paul C. Anagnostopoulos via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Thanks, David. I have started a new document titled

Thanks David! > On Nov 9, 2018, at 08:36, David Greene <dag at cray.com> wrote: > > Daniel Sanders via llvm-dev <llvm-dev at lists.llvm.org> writes: > >> I've been working on the GlobalISel combiner recently and I'd like to >> share the plan for how Combine Rules will be defined in GlobalISel and >> solicit feedback on it. > > This is

Le mer. 28 nov. 2018 à 10:34, Amara Emerson <aemerson at apple.com> a écrit : > > > On Nov 27, 2018, at 5:01 PM, Quentin Colombet via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Hi Daniel, > > Let me try to clarify my concern. > > Le mar. 27 nov. 2018 à 14:23, Daniel Sanders > <daniel_l_sanders at apple.com> a écrit : > > > >

I'm trying to write a tablegen pattern to that matches a sequence of SDNodes and emits again an SDNode and another instruction. The pattern I've written looks like the folowing: def : Pat<(foo (bar GPR:$rs1), simm12:$imm1), (bar (BAZ GPR:$rs1, simm12:$imm1))>; foo and bar are SDNodes, BAZ is an instruction. In particular, bar is defined as follows: def bar :

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

> On Nov 13, 2018, at 08:01, David Greene <dag at cray.com> wrote: > > Daniel Sanders via llvm-dev <llvm-dev at lists.llvm.org> writes: > >> That's an interesting idea. Certainly tablegenerating InstCombine >> ought to be possible and sharing code sounds like it ought to be >> doable. MIR and IR are pretty similar especially after IRTranslator

Eric Christopher <echristo at gmail.com> writes: > +David Greene<mailto:dag at cray.com> as someone who might have an opinion. > > I don't have a strong opinion, but if someone wants to try to make the > docs better and more friendly to them I'm totally down :) Thanks for the CC. I think combining them makes sense. I recall having similar issues finding things

On Friday 05 June 2009 17:41, Dan Gohman wrote: > How is bc_memopv4i32 defined? The bitconvert in the tablegen > output is marked isInt, which means it's the node that didn't get > inferred. def bc_memopv4i32 : PatFrag<(ops node:$ptr), (bitconvert (memopv4i32 node:$ptr))>; -Dave

Can you give an example of where you would use such a feature? It seems entirely too abstract (at least to me) at the moment. On Tue, Apr 7, 2009 at 1:11 AM, David Greene <dag at cray.com> wrote: > I've got another idea for a tblgen extension but I don't have a good feel > for > how feasible it is. Hopefully someone can provide guidance. > > What I want to do is

tl;dr: is anyone opposed to making the interface to a TableGen backend be: void MyBackend(RecordKeeper &, raw_ostream & /* maybe some other args, per backend's needs */); ?? Currently, this is the "interface" for a TableGen backend: struct TableGenBackend { virtual void anchor(); virtual ~TableGenBackend() {} // run - All TableGen backends should implement the run

Hi All, I've been working on the GlobalISel combiner recently and I'd like to share the plan for how Combine Rules will be defined in GlobalISel and solicit feedback on it. This email ended up rather long so: TL;DR: We're planning to define GlobalISel Combine Rules using MIR syntax with a few bits glued on to interface with the algorithm and escape into C++ when we need to.

On Oct 11, 2011, at 1:07 PM, Jim Grosbach wrote: > Perhaps a minor note, but can I'd prefer we call them something other than a "for loop." That implies a more procedural nature than is natural for the language. TableGen is far more declarative that procedural. Even something simple like using a "for each" type syntax and refering to the construct as a "for each

Hello LLVM-Dev, I understand that Uses and Defs are for implicit registers. Uses is defined as for using non-operand registers and Defs is defined as for modifying non-operand registers. For example, for compare and compare with carry instructions, is my understanding correct that the instructions should be defined as described below? Considering that the carry flag is part of the status

The following is an extraction from the Operand class hierarchy of Target.td. I am trying to define a parameterized version of AsmOperandClass with a passed-in bit size. // from Target.td class AsmOperandClass { string Name; } class Operand { AsmOperandClass ParserMatchClass; } // A parameterized AsmOperandClass class myAsmOperandClass<int n> : AsmOperandClass { string Name =

On Nov 4, 2008, at 12:12 AM, Matthijs Kooijman wrote: > Hi Dan, > >> Having tblgen pretend that the MOVE isn't the root seems a bit >> counter-intuitive though. > I didn't really mean making RD the root, but rather telling tablegen > that RD > is the "primary" node, corresponding to the input pattern. This > would allow > the properties of

I've got another idea for a tblgen extension but I don't have a good feel for how feasible it is. Hopefully someone can provide guidance. What I want to do is something like this: class C1<int A, string B> { int foo = A; string bar = B; } class Bb<int A> : C1<A, "foo">; class Cb<int A> : C1<A, "bar">; class C2<C1 Base, int

Le mer. 28 nov. 2018 à 11:41, David Greene <dag at cray.com> a écrit : > > Quentin Colombet <quentin.colombet at gmail.com> writes: > > > And are there any realistic alternatives for declarative > > representations combines? > > > > Realistic I would have thought we can use the syntax we already have > > for SDISel. > > In other

If the patterns only include SDNodes, then pattern fragments will work. I might be wrong, but I've yet to find a way to do it with machine instructions, which is what you seem to have here. Micah > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Sebastian Pop > Sent: Tuesday, June 19, 2012 3:39 PM > To:

> On Nov 10, 2018, at 03:28, Nicolai Hähnle <nhaehnle at gmail.com> wrote: > > Thank you for the detailed reply! There's a lot to digest :) Let me try to address most of it. > > > [snip] >>> I also think you should have 'ins' and 'outs' separately; after all, a predicate may have to do a combined check on two matched registers / operands,

On Oct 11, 2011, at 2:03 PM, David Blaikie wrote: > I'd assume something like: > > for (x, y) = [(1, 4), (2, 5), (3, 6)] in { ... } > > Though I don't know a great deal about tablegen syntax. But so long as the lists are separate it seems it'd always be unclear that it was a zip. +1 Nobody actually needs the zip functionality anyway. /jakob -------------- next