Reapply "Linker: Drop function pointers for overridden subprograms"
authorDuncan P. N. Exon Smith <dexonsmith@apple.com>
Thu, 26 Mar 2015 18:35:30 +0000 (18:35 +0000)
committerDuncan P. N. Exon Smith <dexonsmith@apple.com>
Thu, 26 Mar 2015 18:35:30 +0000 (18:35 +0000)
commit387a89bb36453618bdd7b9407caa74946ec989a9
tree770c578f4d4eeac0f3588af8c4f2c082b44e00cb
parentc8a807c1c5cac5f1afdb911fc6bea582af5e8883
Reapply "Linker: Drop function pointers for overridden subprograms"

This reverts commit r233254, effectively reapplying r233164 (and its
successors), with an additional testcase for when subprograms match
exactly.  This fixes PR22792 (again).

I'm using the same approach, but I've moved up the call to
`stripReplacedSubprograms()`.  The function pointers need to be dropped
before mapping any metadata from the source module, or else this can
drop the function from new subprograms that have merged (via Metadata
uniquing) with the old ones.  Dropping the pointers first prevents them
from merging.

**** The original commit message follows. ****

Linker: Drop function pointers for overridden subprograms

Instead of dropping subprograms that have been overridden, just set
their function pointers to `nullptr`.  This is a minor adjustment to the
stop-gap fix for PR21910 committed in r224487, and fixes the crasher
from PR22792.

The problem that r224487 put a band-aid on: how do we find the canonical
subprogram for a `Function`?  Since the backend currently relies on
`DebugInfoFinder` (which does a naive in-order traversal of compile
units and picks the first subprogram) for this, r224487 tried dropping
non-canonical subprograms.

Dropping subprograms fails because the backend *also* builds up a map
from subprogram to compile unit (`DwarfDebug::SPMap`) based on the
subprogram lists.  A missing subprogram causes segfaults later when an
inlined reference (such as in this testcase) is created.

Instead, just drop the `Function` pointer to `nullptr`, which nicely
mirrors what happens when an already-inlined `Function` is optimized
out.  We can't really be sure that it's the same definition anyway, as
the testcase demonstrates.

This still isn't completely satisfactory.  Two flaws at least that I can
think of:

  - I still haven't found a straightforward way to make this symmetric
    in the IR.  (Interestingly, the DWARF output is already symmetric,
    and I've tested for that to be sure we don't regress.)
  - Using `DebugInfoFinder` to find the canonical subprogram for a
    function is kind of crazy.  We should just attach metadata to the
    function, like this:

        define weak i32 @foo(i32, i32) !dbg !MDSubprogram(...) {

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233302 91177308-0d34-0410-b5e6-96231b3b80d8
lib/Linker/LinkModules.cpp
test/Linker/Inputs/subprogram-linkonce-weak-odr.ll [new file with mode: 0644]
test/Linker/Inputs/subprogram-linkonce-weak.ll [new file with mode: 0644]
test/Linker/replaced-function-matches-first-subprogram.ll
test/Linker/subprogram-linkonce-weak-odr.ll [new file with mode: 0644]
test/Linker/subprogram-linkonce-weak.ll [new file with mode: 0644]