[llvm-dev] TableGen enhancements

[Chris Lattner via llvm-dev]

My sense (which is mostly historic, I haven’t worked on the code generators for a long time sadly) is that tblgen is reasonable with syntactic and other errors.  However, it doesn’t maintain the location info in the AST, so if a tblgen backend wants to report something that is wrong, it points back up to the top level records more often than not.

For example, consider if someone writes an invalid pattern like:

 (ADDrr32 EAX, AL)

The AL def is for an 8 bit register, but the instruction requires a 32-bit register.  The error message should point to the “AL” token on that line when it complains about it.

This is very dated memory, it is possible someone already fixed this up.

-Chris

> On Aug 29, 2020, at 4:04 PM, Paul C. Anagnostopoulos <paul at windfall.com> wrote:
> 
> It's interesting that you bring this up. I've seen a lot of TableGen error messages over the past couple of weeks and I don't recall being confused about any error or its location. I will give this a closer look.
> 
> I agree that syntactic enhancements aren't particularly exciting by themselves. I was wondering whether some new features coupled with new backends would pave the way for additional uses for TableGen in the area of code generation (or any other areas, for that matter).
> 
> At 8/29/2020 06:50 PM, Chris Lattner wrote:
>> Instead of syntactic enhancements, I think it would be great to invest in the internal infrastructure in the implementation of TableGen.
>> 
>> People frequently complain about the quality of error messages in TableGen.  One big reason for this is that we don’t track source locations very well in the “tablegen AST”.  I think that fixing that would be a really nice step towards upgrading the individual diagnostics.
>> 
>> -Chris
>