Paul C. Anagnostopoulos via llvm-dev
2020-Aug-03 15:59 UTC
[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.
Gabriel Hjort Åkerlund via llvm-dev
2020-Aug-04 06:46 UTC
[llvm-dev] TableGen trace facility
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.
Paul C. Anagnostopoulos via llvm-dev
2020-Aug-04 21:10 UTC
[llvm-dev] TableGen trace facility
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