[llvm-dev] TableGen trace facility

[Paul C. Anagnostopoulos via llvm-dev]

Yes, I understand the problem. To be more useful, TableGen would have to carry the traces along with the classes and records and (re)display the values while the substitutions are being made.

I'm writing a new Programmer's Guide for TableGen and have been digging into the parse-time versus substitution-time issue. I haven't found a document that makes it clear. Can you give a quick summary of the phases? 

At 8/4/2020 05:01 PM, Nicolai Hähnle wrote:
>On Mon, Aug 3, 2020 at 6:04 PM Paul C. Anagnostopoulos via llvm-dev
><llvm-dev at lists.llvm.org> wrote:
>> A question for those of you who have developed complex TableGen files: Do you think a trace facility would be useful during debugging? The idea is to add a new statement to TableGen along these lines:
>>
>>   trace tag : value1, value2, ... ;
>>
>> When encountered, the TableGen parser would display the tag along with the values of the specified value1, value2, etc. The tag is an identifier that makes it easier to distinguish multiple traces.
>
>I'm not so sure that that's particularly useful or how it would even
>work. The issue is that at the point in time where the frontend parses
>those trace tags, most substitutions haven't taken place yet, so
>you'll usually get fairly trivial answers that by themselves aren't
>particularly helpful.
>
>Some form of inspection of how values are substituted would indeed be
>helpful, I just don't think the "trace" is quite it. In a perfect
>world, we'd have some sort of "record database explorer" that doesn't
>just let you look at all the final records (TableGen already allows
>you to do that), but also allows you to interactively explore their
>"history", i.e. how did the records come to be.
>
>Cheers,
>Nicolai
>
>-- 
>Lerne, wie die Welt wirklich ist,
>aber vergiss niemals, wie sie sein sollte.