Paul C. Anagnostopoulos via llvm-dev
2020-Aug-09 16:33 UTC
[llvm-dev] Another possible tracing feature for TableGen
I had another idea for a TableGen tracing feature and would like some feedback. It's quite possible I'm on the wrong track here and that improved backend tracing is what folks really need. The idea is to add a -trace option to the tblgen command line. With it you can list one or more record names. TableGen would produce a detailed trace of how the record is built: class inheritances, template argument values, surrounding let substitutions, record field values, etc. An anonymous record could be traced once you knew its name. It might make sense to include a trace level, too, since a fully detailed trace might sometimes show too much information.
Madhur Amilkanthwar via llvm-dev
2020-Aug-09 16:36 UTC
[llvm-dev] Another possible tracing feature for TableGen
I don't think it's on wrong track in fact it is definitely a step in right direction :) We can definitely improvise it over the time but the idea sounds good to me. +1 from my side. On Sun, Aug 9, 2020, 10:03 PM Paul C. Anagnostopoulos via llvm-dev < llvm-dev at lists.llvm.org> wrote:> I had another idea for a TableGen tracing feature and would like some > feedback. It's quite possible I'm on the wrong track here and that improved > backend tracing is what folks really need. > > The idea is to add a -trace option to the tblgen command line. With it you > can list one or more record names. TableGen would produce a detailed trace > of how the record is built: class inheritances, template argument values, > surrounding let substitutions, record field values, etc. An anonymous > record could be traced once you knew its name. > > It might make sense to include a trace level, too, since a fully detailed > trace might sometimes show too much information. > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200809/49210c3b/attachment.html>
Paul C. Anagnostopoulos via llvm-dev
2020-Aug-10 18:24 UTC
[llvm-dev] Another possible tracing feature for TableGen
Since I started a new thread for this idea rather than continuing the previous TableGen tracing thread, I'm replying to invite a few other people to view this thread, in case they missed it. At 8/9/2020 12:36 PM, Madhur Amilkanthwar wrote:>I don't think it's on wrong track in fact it is definitely a step in right direction :) We can definitely improvise it over the time but the idea sounds good to me. > >+1 from my side. > >On Sun, Aug 9, 2020, 10:03 PM Paul C. Anagnostopoulos via llvm-dev <<mailto:llvm-dev at lists.llvm.org>llvm-dev at lists.llvm.org> wrote: >I had another idea for a TableGen tracing feature and would like some feedback. It's quite possible I'm on the wrong track here and that improved backend tracing is what folks really need. > >The idea is to add a -trace option to the tblgen command line. With it you can list one or more record names. TableGen would produce a detailed trace of how the record is built: class inheritances, template argument values, surrounding let substitutions, record field values, etc. An anonymous record could be traced once you knew its name. > >It might make sense to include a trace level, too, since a fully detailed trace might sometimes show too much information.
Nicolai Hähnle via llvm-dev
2020-Aug-13 12:53 UTC
[llvm-dev] Another possible tracing feature for TableGen
On Sun, Aug 9, 2020 at 6:33 PM Paul C. Anagnostopoulos via llvm-dev <llvm-dev at lists.llvm.org> wrote:> I had another idea for a TableGen tracing feature and would like some feedback. It's quite possible I'm on the wrong track here and that improved backend tracing is what folks really need. > > The idea is to add a -trace option to the tblgen command line. With it you can list one or more record names. TableGen would produce a detailed trace of how the record is built: class inheritances, template argument values, surrounding let substitutions, record field values, etc. An anonymous record could be traced once you knew its name. > > It might make sense to include a trace level, too, since a fully detailed trace might sometimes show too much information.I like this idea, it's probably more useful than the original one. The main challenge that comes to mind is that the final name of the record may only be known quite late in the process. Consider a record that is the result of a defm in a multiclass, with inheritance added at multiple steps on the way. During parsing you don't yet know what the final record name is going to be, so it's going to be difficult to filter based on that ;) That said, I'm curious what you come up with to make it happen. Maybe a mode in which *every* record keeps around a bit of data describing where it comes from, so that you can then print it selectively? Cheers, Nicolai> > _______________________________________________ > 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-13 14:04 UTC
[llvm-dev] Another possible tracing feature for TableGen
Ah, yes, tracing defm's is a whole different thing. I'm going to start fooling around with this and see what can be done. I'm learning TableGen at the same time, so nothing will happen quickly. Thanks for your encouragement. At 8/13/2020 08:53 AM, Nicolai Hähnle wrote:>I like this idea, it's probably more useful than the original one. > >The main challenge that comes to mind is that the final name of the >record may only be known quite late in the process. Consider a record >that is the result of a defm in a multiclass, with inheritance added >at multiple steps on the way. During parsing you don't yet know what >the final record name is going to be, so it's going to be difficult to >filter based on that ;) > >That said, I'm curious what you come up with to make it happen. Maybe >a mode in which *every* record keeps around a bit of data describing >where it comes from, so that you can then print it selectively? > >Cheers, >Nicolai