[LLVMdev] Enhancing TableGen

David A. Greene greened at obbligato.org
Fri Oct 7 12:03:53 PDT 2011


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 massive and complicated scheme?  I think we can
>> make some good improvements to the current spec that will help
>> with the MIC work.
>
> I'd like to defer MIC work until it's finalized. But yes, incremental
> refinement is always welcome.

Ok.  I'd like to do some of this incremental work to prepare for MIC.  I
will do this in small batches and please do keep telling me when I'm
heading off track.  :)

>> Frankly, the way things are with the x86 SIMD stuff is not scalable.
>> I'd like to clean some of that up, in an incremental way, of course.
>
> It's not like we are against improvements that make td files
> better. But there is fine balance we should strive for. Readability,
> maintainability, and ease of debugging are very important.

Absolutely.  I don't think I've ever claimed that what I did for AVX
here should go whole hog into upstream.  I certainly never had that view
in my head.  On the contrary, I learned a lot doing it and know all the
mistakes and skeletons quite well.  :)

I'd would like to use that experience to inform how we might structure
the x86 specification a bit better to make maintenance, readability and
debuggability better.

I plan to continue to work on a non-preprocessor for loop because I see
immediate value to it, it is much clearer that what I have currently and
it allows incremental improvements to existing code.

My overarching goal is to get our trees in sync before heavy-duty AVX2
or MIC work begins.

                              -Dave



More information about the llvm-dev mailing list