[LLVMdev] Enhancing TableGen
grosbach at apple.com
Tue Oct 11 13:07:40 PDT 2011
On Oct 11, 2011, at 11:38 AM, David A. Greene wrote:
> 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 with the understanding that it is desired. Please
>>> tell me now if we've changed our minds.
>> No, I think for-loops for top-level defs could be a useful feature.
> Ok, we're on the same page here.
>> I don't want to allow for-loops inside multiclasses. The multiclasses
>> and for-loops provide essentially the same macro functionality with
>> different syntax. Mixing them would lead to a very confusing
> Agreed about multiclasses and for loops implementing similar things.
> Multiclasses are implemented as a big hack in TableGen. They're really
> a pain to deal with, actually. I can see Bruno's tears in the code he
> wrote to allow defms inside multiclasses. :)
> I wonder if we could someday replace multiclasses with a simpler for
> loop syntax. I'll have to think about that. If multiclasses are too
> complicated right now because they spread instruction definitions around
> various classes (I agree with this view), this change might alleviate
> that issue. This kind of thing would have to be considered carefully
> and transitioned slowly, of course. It's just an idea.
> FYI, the way I am implementing for loops means that they *could* work in
> multiple places (e.g. multiclasses) but they do not have to be used that
> way. Restricting for loops to only the top level actually complicates
> things slightly because it becomes a special case.
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 definition" would go a long way. What I want to avoid is any implication that there's a guarantee for order of evaluation.
> I'd like to continue this implementation but of course I would not
> actually try to use them in multiclasses or anywhere else besides the
> top level. Actually, I don't plan to use them at all anytime soon, but
> it sounds like Che-Liang has some immediate needs.
> Does this sound reasonable to you?
> I'll still wait until the 3.0 split to check anything in.
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev