<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Jun 4, 2015 at 8:17 PM Teresa Johnson <<a href="mailto:tejohnson@google.com">tejohnson@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Jun 4, 2015 at 5:33 PM, Reid Kleckner <<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>> wrote:<br>
> On Thu, Jun 4, 2015 at 5:17 PM, Teresa Johnson <<a href="mailto:tejohnson@google.com" target="_blank">tejohnson@google.com</a>> wrote:<br>
>><br>
>> Agreed. Although I assume you mean invoke the new pass under a<br>
>> ThinLTO-only option so that avail extern are not dropped in the<br>
>> compile pass before the LTO link?<br>
><br>
><br>
> No, this pass would actually be an improvement to the standard -O2 pipeline.<br>
> The special case is the regular LTO pass pipeline, which wants to run<br>
> GlobalDCE but doesn't want to drop available_externally function definitions<br>
> until after linker-stage inlining.<br>
<br>
Ok. It looks to me like the LTO compile step with -O2 -flto -c uses<br>
this same -O2 optimization pipeline as without LTO. Clang communicates<br>
the fact that we are doing an LTO compile to llvm via the<br>
-emit-llvm-bc flag, which just tells it to emit bitcode and exit<br>
before codegen. So I would either need to key off of that or setup a<br>
new flag to indicate to llvm that we are doing an LTO -c compile. Or<br>
is there some other way that I am missing?<br>
<br>
Incidentally, we'll also want to skip this new pass and keep any<br>
referenced avail extern functions in the ThinLTO -c compile step for<br>
the same reasons (and there are no imported functions yet at that<br>
point).<br>
<br></blockquote><div><br></div><div>Ultimately for any planned LTO build we're going to want to do a different pass pipeline, it's probably worth considering what should be done before and during LTO.</div><div><br></div><div>-eric</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Teresa<br>
<br>
><br>
> Consider this test case:<br>
><br>
> declare void @blah()<br>
> define i32 @main() {<br>
>   call void @foo()<br>
>   ret i32 0<br>
> }<br>
> define available_externally void @foo() noinline {<br>
>   call void @bar()<br>
>   ret void<br>
> }<br>
> define linkonce_odr void @bar() noinline {<br>
>   call void @blah()<br>
>   ret void<br>
> }<br>
><br>
> If I run opt -O2 on this and feed it to llc, it actually generates code for<br>
> bar, even though there are no actual references to bar in the final code:<br>
><br>
> main:                                   # @main<br>
>         pushq   %rax<br>
>         callq   foo<br>
>         xorl    %eax, %eax<br>
>         popq    %rdx<br>
>         retq<br>
><br>
> bar:                                    # @bar<br>
>         jmp     blah                    # TAILCALL<br>
><br>
> This corner case happens to come up organically with dllimported classes,<br>
> which is why I happened to think of it. :) I'm happy with a flag to<br>
> globaldce for LTO and the original patch, honestly.<br>
<br>
<br>
<br>
--<br>
Teresa Johnson | Software Engineer | <a href="mailto:tejohnson@google.com" target="_blank">tejohnson@google.com</a> | 408-460-2413<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote></div></div>