search for: multidefs

...k I can actually make this work using the existing multidef feature code. The ideas are fundamentally the same. I do like the for syntax a lot better. Che-Liang, would you mind if I played around with changing the multidef parsing to recognize your for syntax? Your code will work in places that multidefs can't right now (as Jakob noted) and we want to retain that ability. I would be working on integrating for loops into TableGen proper, not as a preprocessor. -Dave

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

...k using the existing multidef > feature code. The ideas are fundamentally the same. I do like the > for syntax a lot better. > > Che-Liang, would you mind if I played around with changing the multidef > parsing to recognize your for syntax? Your code will work in places > that multidefs can't right now (as Jakob noted) and we want to retain > that ability. I would be working on integrating for loops into TableGen > proper, not as a preprocessor. +1 for not adding a preprocessor. There seems to be two use cases for this: 1. Generating a sequence of similar top-level d...

On Oct 6, 2011, at 10:01 AM, David A. Greene wrote: > I want to be able to use #..# pasted stuff in a variety of contexts. > For example: > > multiclass blah<string intr> { > for prefix = [<empty>, Vx, Vy] { > for suffix = [ps, pd] { > def #prefix#ADD#suffix# : ProcessSomePattern< > [(set RegClass:$dst,

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

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 throw the Greenspunning term around unless you really mean it. The problem I solved via multidefs was this: how does one write a set of Pat<> patterns i...

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

On Oct 7, 2011, at 11:23 AM, David A. Greene wrote: > Evan Cheng <evan.cheng at apple.com> writes: > >> David, we cannot accept the 'multidef' keyword. Please revert it. > > Working on it now. Thanks. > >> We appreciate you thinking ahead about MIC, but we are against the >> massive refactoring and complicated abstraction scheme. We'll never

Evan Cheng <evan.cheng at apple.com> writes: > On Oct 7, 2011, at 11:23 AM, David A. Greene wrote: > >> Evan Cheng <evan.cheng at apple.com> writes: >> >>> David, we cannot accept the 'multidef' keyword. Please revert it. >> >> Working on it now. > > Thanks. No problem. I agree that multidef was sort of a half-baked idea. I did

On Oct 7, 2011, at 11:23 AM, David A. Greene wrote: > 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 >>

Mark, did you get anywhere with this? We have a similar issue, where a family of otherwise-identical instructions operates on different register classes depending on a non-static property -- functional unit selection in our case. I started to head down the path of using multidefs but quickly abandoned that. I had envisioned a MachineOperand that would hold the functional unit assignment, and having a pass that used that to set up register constraints rather than getting them from the static tables. For your case, can you not simply define the two 32-bit halves as subregist...

Hello. I am a Linux neophyte and know almost nothing ?about compiling, so I would appreciate any help and advice y'all would care to offer. I am trying to compile the 64 bit version of R using a tuned ATLAS and LAPACK (ATLAS 3.9.24). I am running Ubunto 10.04 LTS (through wubi, FWIW). The ATLAS and LAPACK files (atlas.so, f77blas.so, lapack.so, and cblas.so) are sitting in the folder

...mdev at cs.uiuc.edu> Message-ID: <A19B9B72-5673-4463-AF0D-AC286D5EBD5D at apple.com> Content-Type: text/plain; CHARSET=US-ASCII 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 ------------------------------ Message: 5 Date: Wed, 5 Oct 2011 18:43:53 -0600 From: Gang-Ryung Uh <guh at boisestate.edu> Subject: Re: [LLVMdev] MIPS 32bit code gene...

David and Che-Liang, thank you for your hard work on this. Let me clarify what we may accept and what we cannot. Che-Liang, we cannot accept TGPreprocessor. Please revert it as soon as possible. The for-loop syntax is still being discussed, it's not yet clear what we will end up accepting. Please work with Jakob on this. David, we cannot accept the 'multidef' keyword. Please revert

greened at obbligato.org (David A. Greene) writes: > Also, I know I introduced the #..# "pasting" operation but I've found it > to be too limiting. In this example: [snip!] > what if we instead did this: > > (Equivalent TableGen code with a for-loop) > ---------------------------------------- > multiclass PTX_FLOAT_4OP<string opcstr, SDNode opnode1, SDNode

On Oct 7, 2011, at 11:23 AM, David A. Greene wrote: > Evan Cheng <evan.cheng at apple.com> writes: > >> Your proposed new TableGen functionalities are interesting but it is >> clearly not where the code owners want it to go. > > Jakob at least seems interested in the for loop stuff. Am I reading you > correctly, Jakob? Having that feature would make a huge

Che-Liang Chiou <clchiou at gmail.com> writes: > My purpose is to eliminate copy-paste style of programming in td files > as much as possible, but only to a point that the new language > constructs do not create too much overhead/readability-downgrade. Yes! > In other words, I am targeting those low-hanging fruit of copy-paste > programmings in td files that are eliminated

...f the Pat<> patterns which tend to be quite complex. I have found several cases where Pat<> patterns existed for some types of, say, add operation but not others, for no apparent reason other than someone added one and forgot to add the others. Pat<> patterns is the whole reason multidefs got developed in the first place. I wanted to define Pat<> patterns right in the same place the "ordinary" patterns got defined. There's much less chance of missing something or writing inconsistent patterns that way. For x86, I also find the encoding details at the top level...