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

[David Blaikie via llvm-commits]

Also meant to ask whether there was a way to avoid passing in a constant
from the two callers and then conditionalizing later. It'd be nice to just
bubble up the behavior and do it in the place that needs it and not do it
in the place that doesn't.

Not sure if that's possible/practical (I see it overlaps with the 'minimal'
flag, which makes it trickier) - but I'll give it some more thought.

On Fri, Apr 1, 2016 at 2:38 PM, David Blaikie via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> 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
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160401/5b2aa574/attachment.html>