llvm dev - Aug 2020 - TableGen trace facility

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 think such a feature would be very helpful if the trace can be used to print 
arbitrary parts of patterns. I often find that when a pattern is rejected I 
need to strip down the *.td file, fire up gdb, set up breakpoints or step to 
where the pattern is rejected, and inspect the current tree pattern. Having 
the ability to insert trace points directly into the pattern would save me 
this effort.

Cheers,
Gabriel

-----Original Message-----
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Paul C. 
Anagnostopoulos via llvm-dev
Sent: den 3 augusti 2020 18:00
To: llvm-dev at lists.llvm.org
Subject: [llvm-dev] TableGen trace facility

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.

_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6320 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200804/d8b7d7ed/attachment.bin>

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.

Hi Gabriel,

On Tue, Aug 4, 2020 at 8:46 AM Gabriel Hjort Åkerlund via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> I think such a feature would be very helpful if the trace can be used to
print
> arbitrary parts of patterns. I often find that when a pattern is rejected I
> need to strip down the *.td file, fire up gdb, set up breakpoints or step
to
> where the pattern is rejected, and inspect the current tree pattern. Having
> the ability to insert trace points directly into the pattern would save me
> this effort.
It's important to distinguish between the TableGen frontend, which is
the thing that parses .td files, expands defm's, evaluates
substitutions, etc., and the backends, which take the resulting record
database as input and generate some output.

What you're describing sounds more like problems with a backend (the
SelectionDAG ones, I assume?), and I don't see how what Paul sketched
very briefly would help you there. You're probably aware that running
TableGen with the default backend will dump the entire record database
as text, so that you can inspect the result of substitutions and check
whether the resulting pattern records really are what you expect? Once
you've done that, if you run into further problems with the backend
rejecting a pattern, you'd really need some sort of backend-specific
help.

Cheers,
Nicolai



>
> Cheers,
> Gabriel
>
> -----Original Message-----
> From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Paul
C.
> Anagnostopoulos via llvm-dev
> Sent: den 3 augusti 2020 18:00
> To: llvm-dev at lists.llvm.org
> Subject: [llvm-dev] TableGen trace facility
>
> 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.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


-- 
Lerne, wie die Welt wirklich ist,
aber vergiss niemals, wie sie sein sollte.

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.

Gabriel Hjort Åkerlund via llvm-dev <llvm-dev at lists.llvm.org> writes:
> I think such a feature would be very helpful if the trace can be used to
print
> arbitrary parts of patterns. I often find that when a pattern is rejected I
> need to strip down the *.td file, fire up gdb, set up breakpoints or step
to
> where the pattern is rejected, and inspect the current tree pattern. Having
> the ability to insert trace points directly into the pattern would save me 
> this effort.
The way I usually debug these is open up the generated selection .inc
for the target (beware, it's HUGE!) and do a compiler run with
-debug-only=isel,x86-isel (for example).  The debug dump shows the steps
the isel interpreter takes along with the "addresses" of branch points
and targets where the interpreter makes decisions.  These "addresses"
are comments in the .inc file and one can step through it by following
the printouts in the debug dump.  That way one can see where things go
wrong.  I would say 95% of the time I can find the problem this way.

One thing that would help tremendously is reducing the size of the .inc,
either by splitting it into multiple files or by some other method.

               -David