[LLVMdev] Enhancing TableGen

[Jim Grosbach]

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

Regards,
-Jim

> 
> 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.
> 
>                                -Dave
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev