similar to: [LLVMdev] Multiclass inheritance?

On Mar 23, 2009, at 5:14 PM, David Greene wrote: > In TableGen, can multiclasses inherit from one another? I notice > that there's > a lot of redundancy in the X86 .td files that could go away with > multiclass > inheritance. Nope, not currently. That would be a nice feature though! -Chris

I have been reading the “RFC/bikeshedding: Separation of instruction and pattern definitions in LLVM backends” topic with considerable interest. This is an approach I have been considering for taming our own large instruction set, and it looks like it structures our descriptions better than the conventional approach we have used so far. However, I have another form of TableGen taming that I

Hi list, I'm toying with the idea of writing a m680x0 backend for LLVM, and the address modes of this chip are bewildering, to say the least. Here's a rough list off wikipedia for reference: * Register direct o data register, e.g. "D0" o address register, e.g. "A6" * Register indirect o Simple address, e.g. (A0) o

On 08/22/2017 03:59 AM, Alex Bradbury via llvm-dev wrote: > On 21 August 2017 at 13:23, Martin J. O'Riordan via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> But there is a downside. >> >> For each of the above I also have variations that are a result of different >> processor and ISA versions, and because of this I have to use >> ‘multiclass/defm’

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

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

greened at obbligato.org (David A. Greene) writes: > The problem I solved via multidefs was this: how does one write a set of > Pat<> patterns in a generic way? > > For example, I want to be able to do this: > > defm MOVH : > vs1x_fps_binary_vv_node_rmonly< > 0x16, "movh", undef, 0, > // rr > [(undef)], >

greened at obbligato.org (David A. Greene) writes: > So here's why I think the for loop proposal can't be a preprocessing > phase. Down in the guts of this I fundamentally need to be able to do > this: > > multiclass blah<list<int> Values> { > for v = Values { > def DEF#v : base_class<v>; > } > } > > Will that work? Is the for

On Aug 1, 2012, at 1:53 PM, Jyotsna Verma <jverma at codeaurora.org> wrote: > > Currently, we rely on switch tables to transform between formats. However, > we would like to have a different mechanism to represent these relationships > instead of switch tables. I am thinking of modeling these relations in > HexagonInstrInfo.td file and use TableGen to generate a table with

Hi Jakob and David, The for-loop inside multiclass definition does not have to add extra abstraction layer. As in the pseudo codes that David wrote earlier (see below), it only condenses the repetitive 'def' statements inside the multiclass definition into a more compact and less copy-paste style form, instead of encapsulating them somewhere outside the multiclass definition. I believe

On Oct 6, 2011, at 12:42 PM, David A. Greene wrote: > Jakob Stoklund Olesen <jolesen at apple.com> writes: > >> On Oct 6, 2011, at 7:59 AM, David A. Greene wrote: >> >>> For example, I want to be able to do this: >>> >>> defm MOVH : >>> vs1x_fps_binary_vv_node_rmonly< >>> 0x16, "movh", undef, 0, >>>

On Mon, Feb 9, 2009 at 5:17 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > Is there a way to define a multi-class pattern in tablegen? > Yes. See "multiclass" and "defm" in, say, X86Instr64bit.td, et al. -bw

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

The TableGen language seems to be growing Lisp macros from two different directions. Che-Liang Chiou added a preprocessor with for loops, and David Greene added multidefs. It seems that some kind of macro facility is needed, perhaps we should discuss what it is supposed to look like? /jakob

On Oct 6, 2011, at 7:59 AM, David A. Greene wrote: > For example, I want to be able to do this: > > defm MOVH : > vs1x_fps_binary_vv_node_rmonly< > 0x16, "movh", undef, 0, > // rr > [(undef)], > // rm > [(set DSTREGCLASS:$dst, > (DSTTYPE (movlhps SRCREGCLASS:$src1, >

Jakob Stoklund Olesen <jolesen at apple.com> writes: > The TableGen language seems to be growing Lisp macros from two > different directions. > > Che-Liang Chiou added a preprocessor with for loops, and David Greene > added multidefs. > > It seems that some kind of macro facility is needed, perhaps we should > discuss what it is supposed to look like? Don't

Bill, Sorry if I wasn't clear enough. I wasn't referring to multiclass's that define other classes, but with using patterns inside of a multiclass to reduce redundant code. For example: multiclass IntSubtract<SDNode node> { def _i8 : Pat<(sub GPRI8:$src0, GPRI8:$src1), (ADD_i8 GPRI8:$src0, (NEGATE_i8 GPRI8:$src1))>; def _i32 : Pat<(sub

Evan Cheng <evan.cheng at apple.com> writes: > David, we cannot accept the 'multidef' keyword. Please revert it. Working on it now. > We appreciate you thinking ahead about MIC, but we are against the > massive refactoring and complicated abstraction scheme. We'll never > accept those patches. How about a less massive and complicated scheme? I think we can make

Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: >> Yes, I get it. I think I have said that before. > > Excellent. I am sorry for the harsh tone, but you seemed to have > completely missed the point of the thread. E-mail is often a poor communication medium. :-/ >> I will not change anything before the 3.0 branch. But I am working on >> this functionality

On Oct 6, 2011, at 10:25 AM, David A. Greene wrote: > greened at obbligato.org (David A. Greene) writes: > >> So here's why I think the for loop proposal can't be a preprocessing >> phase. Down in the guts of this I fundamentally need to be able to do >> this: >> >> multiclass blah<list<int> Values> { >> for v = Values { >>