search for: globaldce

...0:04 AM, David Blaikie <dblaikie at gmail.com> >>> wrote: >>> > >>> > >>> > On Fri, May 15, 2015 at 9:53 AM, Teresa Johnson <tejohnson at google.com> >>> > wrote: >>> >> >>> >> Looking back through my GlobalDCE changes, it looks like one of the >>> >> places I had changed (where we mark defined globals in runOnModule) >>> >> already has a guard for !hasAvailableExternallyLinkage and >>> >> !isDiscardableIfUnused, so my additional guard against marking >>&...

...>>> > >> >>> > >> >>> > On Fri, May 15, 2015 at 9:53 AM, Teresa Johnson >> >>> > <tejohnson at google.com> >> >>> > wrote: >> >>> >> >> >>> >> Looking back through my GlobalDCE changes, it looks like one of the >> >>> >> places I had changed (where we mark defined globals in runOnModule) >> >>> >> already has a guard for !hasAvailableExternallyLinkage and >> >>> >> !isDiscardableIfUnused, so my additional guar...

...>> >> >>> > On Fri, May 15, 2015 at 9:53 AM, Teresa Johnson >> >> >>> > <tejohnson at google.com> >> >> >>> > wrote: >> >> >>> >> >> >> >>> >> Looking back through my GlobalDCE changes, it looks like one of >> >> >>> >> the >> >> >>> >> places I had changed (where we mark defined globals in >> >> >>> >> runOnModule) >> >> >>> >> already has a guard for !hasAvailable...

...pipeline > that deletes all of them (referenced or not) -- it's just a single loop > through all the functions deleting the bodies of those with the right > linkage. I imagine there are other pass pipelines that might want to do > something similar. I don't really like having GlobalDCE delete them > (even behind a flag) because they aren't actually dead, and I think a > separate pass makes it easier to test and all that. (I haven't actually > worked much with pass pipelines, though, so there's a chance I'm on my > own here?) > It's possible to...

...st the >>> always-inliner at compile time, deferring almost all inlining until >>> later. >> >> Note that one of the sets of SPEC cpu2006 data I collected was with >> full LTO. I'm trying to understand where this would be an issue for >> full LTO, since GlobalDCE is running after inlining in the link time >> LTO pipeline. >> >> Just to be clear, are you concerned about the following: >> >> 1) GlobalDCE run after inlining in the "-flto -O2 -c" build removes an >> unreferenced available externally function >&gt...

...>>>> On Fri, May 15, 2015 at 9:53 AM, Teresa Johnson >>>>>>>>>> <tejohnson at google.com> >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Looking back through my GlobalDCE changes, it looks like one of >>>>>>>>>>> the >>>>>>>>>>> places I had changed (where we mark defined globals in >>>>>>>>>>> runOnModule) >>>>>>>>>>> already has a gua...

...apple.com> wrote: > >> On 2015 Jun 4, at 16:51, Reid Kleckner <rnk at google.com> wrote: >> >> 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 the LTO pass pipeline, where the code will be reloaded and reoptimized later. IMO it's natural to put...

Hi, when I run opt -globaldce -deadargelim on a module, deadargelim removes less arguments than when I run opt separately for the two passes. The module has dead functions that hold references to other functions, which makes the latter intrinsically live for deadargelim. -debug-pass=Executions shows no other passes being ru...

...ve these > > LLVM doesn't have an -flto flag, so I'd probably keep this generic to > "compiling an object file for later LTO". Ok > > + // so they are eligible for inlining at link-time. Note if they > + // are unreferenced they will be removed by GlobalDCE below, so > + // this only impacts referenced available externally globals. > + // Eventually they will be suppressed during codegen, but > eliminating > + // here is a compile-time savings. > > More than the compile time savings, it actually increases the pow...

...; procedure, inside file2.in.bc. However, the inlined function is still in the > bitcode, even though it is unreachable from main. Is there a way to remove > this unreachable function from the bitcode file? > > thank you very much, > > Gabriel > Try "-inline -internalize -globaldce", should do the trick. The -globaldce by itself is the pass that does what you want (remove unreachable functions among other things), but the -internalize marks all functions as internal (otherwise they're reachable via their exported symbols, and so globaldce cannot remove them). Hope...

...t 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...

...allyLinkage, unless it has link once linkage. > > As far as using that to indicate that it is an aux function, I was > concerned about overloading the meaning of that linkage type. See the > next para for an example where I am unsure about doing this... > > Looking back through my GlobalDCE changes, it looks like one of the > places I had changed (where we mark defined globals in runOnModule) > already has a guard for !hasAvailableExternallyLinkage and > !isDiscardableIfUnused, so my additional guard against marking > imported functions is unnecessary. But the other place...

Dear LLVMers, I am trying to use your inline pass, and I would like to know if it is possible to remove a function from the bitcode file once it is inlined. Basically, I try: $> opt -inline file2.bc > file2.in.bc and I see that all the functions have been inlined into the main procedure, inside file2.in.bc. However, the inlined function is still in the bitcode, even though it is

...; the way GCC used to work. Thanks for explaining. Why not redefine it from historical anachronism to architectural flag, that indicates you may generate more code with the same functions and globals later? And then, you could pass the same flag to createStandardLTOPasses, and that would skip the GlobalDCE passes. >> Even then, my runtime function prorotypes are still being stripped away by the GlobalDCE added by createStandardLTOPasses. > > Sure, and why not? Unused prototypes are not used for anything, they won't > turn up in the generated code for example. They are not used...

...ass 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 llv...

...ink links and there appears to be > no regressions in the resulting code. I take it that LTO > in llvm 2.5 is still limited to dead code elimination, > correct? No. libLTO does the equivalent to opt -internalize -ipsccp -globalopt -constmerge -deadargelim -instcombine -inline -prune-eh -globaldce -argpromotion -instcombine -jump-threading -scalarrepl -globalsmodref-aa -licm -gvn -memcpyopt -dse -instcombine -jump-threading -mem2reg -simplifycfg -globaldce Will LTO ever be extended to inlining across > files as well as constant-folding and global data > allocation optimizations?...

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 the LTO pass pipeline, where the code will be reloaded and reoptimized > later. IMO it...

I've had better luck compiling all of pymol 1.1r2 with -O4 on darwin9. Everythink links and there appears to be no regressions in the resulting code. I take it that LTO in llvm 2.5 is still limited to dead code elimination, correct? Will LTO ever be extended to inlining across files as well as constant-folding and global data allocation optimizations? Or does the reliance on gcc-4.2 as the

On 8 Jun 2015, at 21:08, Eric Christopher <echristo at gmail.com> wrote: > > I'd rather not have it be an llvm option at all. Just construct a different set of passes... > > This would also solve the problem of needing multiple sets of options to be passed to the builder. It'd be a bit of a change (i.e. having clang do the pass setup), but I think it'd be worth it

...to work. > > Thanks for explaining. > > Why not redefine it from historical anachronism to architectural flag, that indicates you may generate more code with the same functions and globals later? And then, you could pass the same flag to createStandardLTOPasses, and that would skip the GlobalDCE passes. LTO is for doing optimizations that are only valid when the module contains everything that is needed to build the final executable. So adding a flag to say "not everything is there after all" makes no sense to me. >>> Even then, my runtime function prorotypes are stil...