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

Reid Kleckner rnk at google.com
Mon Jun 8 11:52:39 PDT 2015


On Mon, Jun 8, 2015 at 11:46 AM, Teresa Johnson <tejohnson at google.com>
wrote:

> On Mon, Jun 8, 2015 at 11:33 AM, Reid Kleckner <rnk at google.com> wrote:
> > The clang patch lgtm, and I had some comments on the LLVM patch. Duncan,
> do
> > you want to say more there?
> >
> > --- include/llvm/Transforms/IPO/PassManagerBuilder.h (revision 237590)
> > +++ include/llvm/Transforms/IPO/PassManagerBuilder.h (working copy)
> > @@ -121,6 +121,7 @@ class PassManagerBuilder {
> >    bool VerifyInput;
> >    bool VerifyOutput;
> >    bool MergeFunctions;
> > +  bool LTO;
> >
> > While in the context of clang it makes sense that "LTO" means "generate
> an
> > object file appropriate for later LTO", but in the context of LLVM, it
> might
> > be taken to mean "we are doing LTO optimizations now". I think we
> probably
> > want to name the boolean something more specific (PreLTO?
> CompileForLTO?).
> > Later if we customize further we can split the codepath as is done for
> > populateLTOPassManager.
>
> Yeah, I was concerned that the name might be confusing in this
> context, so if we opt to go with a single llvm option to mean -flto I
> like the idea of something like CompileForLTO (or maybe
> PrepareForLTO?).


I like PrepareForLTO!


> > Do you need to set the linkage of global variables to external? I noticed
> > that Function::deleteBody() does this but setInitializer(nullptr) does
> not.
> > Ditto for aliases.
>
> Hmm, I am not sure - I basically am doing the same things GlobalDCE
> does (aside from erasing them from the function/variable/alias list).
> I guess it didn't matter in the GlobalDCE case since they were being
> completely erased rather than leaving a decl behind. Will make that
> change and retest.
>

Sounds good.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150608/da7e8ef8/attachment.html>


More information about the llvm-dev mailing list