[llvm-bugs] [Bug 27284] New: Reverse the ownership between DICompileUnit and DISubprogram

via llvm-bugs llvm-bugs at lists.llvm.org
Fri Apr 8 08:49:20 PDT 2016


            Bug ID: 27284
           Summary: Reverse the ownership between DICompileUnit and
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: DebugInfo
          Assignee: unassignedbugs at nondot.org
          Reporter: aprantl at apple.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Created attachment 16187
  --> https://llvm.org/bugs/attachment.cgi?id=16187&action=edit
a python script that updates LLVM IR testcases to the new format

Currently each Function points to a DISubprogram and DISubprogram has a scope
field. For member functions the scope is a DICompositeType. DIScopes never
point to the DICompileUnit to facilitate type uniquing.

Distinct DISubprograms (with isDefinition: true) are not part of the type
hierarchy and cannot be uniqued. I'm proposing to remove the subprograms list
from DICompileUnit and instead add a pointer to the owning compile unit to
distinct DISubprograms. This would make it easy for ThinLTO to strip unneeded
DISubprograms and their transitively referenced debug info.


Materializing DISubprograms is currently the most expensive operation when
doing a ThinLTO build of clang.

We want the DISubprogram to be stored in a separate Bitcode block (or the same
block as the function body) so we can avoid having to expensively deserialize
all DISubprograms together with the global metadata. If a function has been
inlined into another subprogram we need to store a reference the block
containing the inlined subprogram.


Attached is a python script that updates LLVM IR testcases to the new format.

You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160408/3a14ace8/attachment.html>

More information about the llvm-bugs mailing list