[PATCH] D14687: Macro support in LLVM IR

[David Blaikie via llvm-commits]

On Tue, Nov 17, 2015 at 1:13 AM, Amjad Aboud via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> aaboud added a comment.
>
> > > If I understood you correctly, you are referring to IR documentation
> that I
>
> >  forgot to update according to these changes, right?
>
> >  >
>
> >
>
> > Yes :).
>
>
> [AA]  OK I will do that when I upload a new patch.
>
> > I'm not speaking about this from the DWARF angle, I really know almost
>
> >  nothing about DWARF.  The IR is used to generate DWARF, but it doesn't
>
> >  actually match the DWARF (from what I understand).  We need to/have the
>
> >  opportunity to figure things out on an as-needed-basis in the backend.
>
> >
>
> > The problem with referring to something from the compile unit is that
> even
>
> >  when the relevant code gets optimized out, we'll still have references
> to the
>
> >  full debug info graph.  This makes bugpoint reduction painful (the
> testcases
>
> >  aren't actually reduced), causes scalability problems for LTO, and
> bloats the
>
> >  debug info with descriptions that the end-user has no need for.
>
> >
>
> > IMO, references from the IR should keep alive the actual macros that are
>
> >  relevant in the emitted object code (after optimizations), and the rest
> should
>
> >  just be dropped.  This is the direction we're generally going with
>
> >  subprograms (hoping to remove the subprograms array from the compile
>
> >  unit soon).
>
> >
>
> > However, I frankly don't understand the whole picture here, since you
> didn't
>
> >  attach any changes to CFE for where macros get inserted into the code.
>
>
> [AA] According to my understanding of macros, the compiler should pass
> them to the debug info as is.


Yep,  just to re-iterate/provide some context for Duncan: This debug info
is to describe macro definitions, not their use. So in codebases that are
macro heavy (like GCC) you can use those macros when evaluating expressions
in your debugger (since in codebases like that it's impractical to interact
with many data structures without the macros).


> That is why they look the same all the way from the preprocessor till they
> are emitted in the object file.
> Optimizations will change nothing in the macro debug info, and it is up to
> other debug info (such as line table) to hide or expose unreachable macros
> from the user.
> In other words, you cannot optimize macros.
> Also, macro debug info is related to the compile unit, so when we link two
> compile units, each will have its own macro debug info.
> In DWARF5 there is a way to share encoding of macros between compile
> unites, but still each will have its own.
>
> It would be great if somebody, who know better than me the macro debug
> info definition, can give his opinion on this point.
>
> > Ah, it doesn't use DW_TAG.  Should we move DINode to DITagNode and
>
> >  then create a common base class called DINode?
>
>
> [AA] I thought that MDNode is the base class, why should we have another
> base class?
> Notice, that I am not doing something new to LLVM debug info, we already
> have the DILocation and DIExpression classes that inherit from MDNode and
> not DINode.
> So, why cannot we have also the DIMacroNode that inherits from MDNode and
> has nothing to do with DINode?
>
>
> Repository:
>   rL LLVM
>
> http://reviews.llvm.org/D14687
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151117/fbf14370/attachment.html>