search for: multidef

...e able to do > this: > > multiclass blah<list<int> Values> { > for v = Values { > def DEF#v : base_class<v>; > } > } > > Will that work? Is the for loop evaluated after parameter binding? I think 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...

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

...; multiclass blah<list<int> Values> { >> for v = Values { >> def DEF#v : base_class<v>; >> } >> } >> >> Will that work? Is the for loop evaluated after parameter binding? > > I think 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...

...> } > } > > It's actually more complex than this but this gives the basic idea. The > key thing I need to be able to do is construct an instrinsic name given > some base string, a prefix and a suffix. David, I think the syntax you are proposing here is much better than the multidef syntax. When I look at test/TableGen/MultiPat.td, I have a really hard time figuring out what is happening. Basically, I don't want our target descriptions to end up looking like that. > Here's a critical question. What type do the for loop iterators have? > string? That's pro...

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

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 >> accept those patches. > > How about a less massi...

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 it for practical purposes here but Che-Liang developed a much better, mroe general solution to the problem. >> How about a less ma...

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 >> accept those patches. > > How about a less massive and com...

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

...APACK_LIBS to pass the folder and libraries, and nothing seems to work. I do not know enough to know if the problem with my ATLAS libraries or if the problem with my attempt at compiling R. If it makes a difference, the ATLAS (3.9.24) needed to be compiled with the --allow-multiple-definitions (-z multidef) option because of what may be a bug (see <http://sourceforge.net/tracker/?func=detail&aid=2998779&group_id=23725&atid=379483> ) I do not know if I could follow the "Shared BLAS" route suggested for ACML/Goto, as ATLAS requires two files (the f77blas library as well). A...

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

...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 it. We find it very confusing and narrow is scope. We appreciate you thinking ahead about MIC, but we are against the massive refactoring and complicated abstraction scheme. We'll never accept those patches. Your proposed new TableGen functionalities are interesting...

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