[LLVMdev] Removing AvailableExternal values in GlobalDCE (was Re: RFC: ThinLTO Impementation Plan)

[Eric Christopher]

On Thu, Jun 4, 2015 at 8:17 PM Teresa Johnson <tejohnson at google.com> wrote:

> On Thu, Jun 4, 2015 at 5:33 PM, Reid Kleckner <rnk at google.com> wrote:
> > On Thu, Jun 4, 2015 at 5:17 PM, Teresa Johnson <tejohnson at google.com>
> wrote:
> >>
> >> Agreed. Although I assume you mean invoke the new pass under a
> >> ThinLTO-only option so that avail extern are not dropped in the
> >> compile pass before the LTO link?
> >
> >
> > No, this pass would actually be an improvement to the standard -O2
> pipeline.
> > The special case is the regular LTO pass pipeline, which wants to run
> > GlobalDCE but doesn't want to drop available_externally function
> definitions
> > until after linker-stage inlining.
>
> Ok. It looks to me like the LTO compile step with -O2 -flto -c uses
> this same -O2 optimization pipeline as without LTO. Clang communicates
> the fact that we are doing an LTO compile to llvm via the
> -emit-llvm-bc flag, which just tells it to emit bitcode and exit
> before codegen. So I would either need to key off of that or setup a
> new flag to indicate to llvm that we are doing an LTO -c compile. Or
> is there some other way that I am missing?
>
> Incidentally, we'll also want to skip this new pass and keep any
> referenced avail extern functions in the ThinLTO -c compile step for
> the same reasons (and there are no imported functions yet at that
> point).
>
>
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.

-eric


> Teresa
>
> >
> > Consider this test case:
> >
> > declare void @blah()
> > define i32 @main() {
> >   call void @foo()
> >   ret i32 0
> > }
> > define available_externally void @foo() noinline {
> >   call void @bar()
> >   ret void
> > }
> > define linkonce_odr void @bar() noinline {
> >   call void @blah()
> >   ret void
> > }
> >
> > If I run opt -O2 on this and feed it to llc, it actually generates code
> for
> > bar, even though there are no actual references to bar in the final code:
> >
> > main:                                   # @main
> >         pushq   %rax
> >         callq   foo
> >         xorl    %eax, %eax
> >         popq    %rdx
> >         retq
> >
> > bar:                                    # @bar
> >         jmp     blah                    # TAILCALL
> >
> > This corner case happens to come up organically with dllimported classes,
> > which is why I happened to think of it. :) I'm happy with a flag to
> > globaldce for LTO and the original patch, honestly.
>
>
>
> --
> Teresa Johnson | Software Engineer | tejohnson at google.com | 408-460-2413
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150605/2b9255cb/attachment.html>