[PATCH] D18706: [DWARF] Force a linkage_name on an inlined subprogram's abstract origin

[David Blaikie via llvm-commits]

dblaikie added a comment.

Got data on how much this grows the size of output (optimized clang selfhost, perhaps?)

I've had a few conversations about where linkage names should and should not appear, and have yet to understand/hear a coherent position about what consumers want to use them for. Perhaps you could outline your use case, so we can at least think about how that applies across LLVM?


================
Comment at: test/DebugInfo/Generic/linkage-name-abstract.ll:10-16
@@ +9,9 @@
+; IR generated from clang -O0 with:
+; int i = 2;
+; __attribute__((always_inline)) int foo() { 
+;   return i;
+; }
+; int bar() { 
+;   return 1 + foo();
+; }
+
----------------
If you're demonstrating inlining, I find this to be the simplest option:

  void f1();
  __attribute__((always_inline)) void f2() {
    f1();
  }
  void f3() {
    f2();
  }

That way there's no confusion about whether the return values are relevant, if the operations (like addition) are relevant, if an optimization could constant propagate/fold away the value, etc. The call to f1 is unoptimizable, can't be coalesced with anything, etc.


http://reviews.llvm.org/D18706