[LLVMdev] First-class debug info IR: MDLocation (original) (raw)
Chandler Carruth chandlerc at google.com
Mon Oct 27 01:19:11 PDT 2014
- Previous message: [LLVMdev] First-class debug info IR: MDLocation
- Next message: [LLVMdev] First-class debug info IR: MDLocation
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Separate reply as the topics seem to have very little in common...
On Fri, Oct 24, 2014 at 4:16 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote:
Making debug info assembly readable and writable ================================================
Moreover, we're now in a place where it's trivial to express the "context" pointer structurally. Here's the same debug info as above, using syntactic sugar to fill the "context" pointers:
FWIW, this doesn't make a huge difference to me in terms of readability other than avoiding ordering problems....
Bike sheds to paint
===================
1. Should we trim some boilerplate? E.g., it would be trivial to change: !6 = metadata MDLocation(line: 43, column: 7, scope: !4) to: !6 = MDLocation(line: 43, column: 7, scope: !4) This would not complicate
LLParser. Thoughts?
If it is metadata, it should use 'metadata'. The boiler plate isn't the problem here IMO.
2. Which of the two "end goal" syntaxes is better: flat, or hierarchical? Better for what? Why?
Some points that might simplify things:
The largest overhead left for humans (once the fields are named and semantically de-obfuscated) are IMO: lack of symbolic constants from DWARF and the lack of locality with the referencing instruction.
I think there is likely a better inflection point in the tradeoff space between normalization and duplication. For example, I would be happy to see line and column repeated for every instruction on the instruction. Every time you save the reader an indirection through some "!019243" (which is totally unremarkable and hard to track) you win unless the size of the input is greatly changed.
The conflict between humans and FileCheck is not as bad as I think you imagine. We have well established techniques for handling cases where what the IR contains isn't useful for FileCheck, and/or what would be useful for FileCheck is terribly cumbersome to write. We have the printer inject comments which can then be used in FileCheck. I think the same technique would tremendously help both human readers (but not writers) and FileCheck with location information. My suggestion: print out a comment line of the form "# location: ..." for all the indirected information every time that indirected information changes, and printed before the first instruction with the new indirected information. If both line or column are attached directly to the instruction, this gives just a comment at the start of each function and after each file change within the function body. Enough to form reasonably bracketed FileCheck but not overly verbose I suspect.
Once you've had an indirection from the actual IR structure to the debuginfo structure embedded down in the metadata, I agree that a structural form looks better.
Hope these thoughts help formulate even better looking IR. Not specifically trying to change any part of this patch or any other single patch. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141027/bd2f8faa/attachment.html>
- Previous message: [LLVMdev] First-class debug info IR: MDLocation
- Next message: [LLVMdev] First-class debug info IR: MDLocation
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]