search for: prepareforlto

...a main function, according to the documentation) which would allow the existing dead global elimination optimization pass to do the job. It seems that InternalizePass is, again understandably, not enabled by default even when you select optimization level 3. How do you turn it on? I tried setting PrepareForLTO but that doesn't seem to do anything. Here's what I have so far: legacy::FunctionPassManager FPM(&M); legacy::PassManager MPM; PassManagerBuilder Builder; Builder.OptLevel = 3; Builder.PrepareForLTO = true; Builder.VerifyInput = true; Builder.VerifyOutput =...

On Thu, Jun 4, 2015 at 3:58 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > Personally, I think the right approach is to add a bool to > createGlobalDCEPass defaulting to true named something like > IsAfterInlining. In most standard pass pipelines, GlobalDCE runs after > inlining for obvious reasons, so the default makes sense. The special case > is

...O?). > 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?). > > + if (!LTO) { > + // Remove avail extern fns and globals definitions if we aren't > + // doing an -flto compilation. For LTO we will preserve these > > LLVM doesn't have an -flto flag, so I'd probably keep this generic to > "compiling...

...s default (off) because when on it caused issue #673 //PMBuilder->NewGVN = !is_debug; PMBuilder->DisableGVNLoadPRE = is_debug; PMBuilder->VerifyInput = assertions_on; PMBuilder->VerifyOutput = assertions_on; PMBuilder->MergeFunctions = !is_debug; PMBuilder->PrepareForLTO = false; PMBuilder->PrepareForThinLTO = false; PMBuilder->PerformThinLTO = false; TargetLibraryInfoImpl tlii(Triple(module->getTargetTriple())); PMBuilder->LibraryInfo = &tlii; if (is_debug) { PMBuilder->Inliner = createAlwaysInlinerLegacyPass(false)...

Talked to Eric Fri and he suggested that this might be the first of several places where we want behavior of LTO compiles to diverge from normal -O2 compiles. So for now I have implemented this such that we pass down -flto to the -cc1 job, and that gets propagated as a code gen option and into the PassManagerBuilder. I have left the current logic translating -flto to the -emit-llvm-bc option,