[PATCH] D14687: Macro support in LLVM IR

[Amjad Aboud via llvm-commits]

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. 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