[LLVMdev] Enhancing TableGen
David A. Greene
greened at obbligato.org
Tue Oct 11 11:38:06 PDT 2011
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.
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.
More information about the llvm-dev