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

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=27284

            Bug ID: 27284
           Summary: Reverse the ownership between DICompileUnit and
                    DISubprogram
           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.

Motivation
----------

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.

Implementation
--------------

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>