[LLVMdev] First-class debug info IR: MDLocation

[Chandler Carruth]

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>