search for: populateltopassmanag

...etting to I think CodeGen then crashing. I've found that the module itself needs to be non-trivial to cause the crash. Here is the module I'm testing with [3]. In case it is relevant: to get my pass to run during LTO I added "PM.add(createHelloPass())" to PassMangerBuilder::populateLTOPassManager. I'm using binutils-gold on Linux (Ubuntu 14.04 LTS). Thank you, Scott A. Carr PhD Candidate Purdue University [1] http://pastebin.com/uL6QMtcT [2] http://pastebin.com/i1gd0gE6 [3] http://pastebin.com/GEG0F8kU

...the full output of -print-after-all [1] and just the module itself after my pass[2]. I've looked over the IR, but I can't see anything obviously wrong. I'm not sure what you meant by: > You may want to try to add it at the end of the pipeline My pass is the last one added inside populateLTOPassManager. Should I add it to the PassManager somewhere else? Thanks, Scott [1] https://gist.github.com/scottcarr/ce0bb6df1cbb44ec46a5 [2] http://pastebin.com/9xc2jpRj On 02/09/2016 01:36 PM, Mehdi Amini wrote: >> On Feb 9, 2016, at 10:24 AM, Scott A. Carr via llvm-dev <llvm-dev at lists.llvm...

On Jul 27, 2013, at 5:47 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > Hi, Sean: > > I'm sorry I lie. I didn't mean to lie. I did try to avoid making a *BIG* change > to the IPO pass-ordering for now. However, when I make a minor change to > populateLTOPassManager() by separating module-pass and non-module-passes, I > saw quite a few performance difference, most of them are degradations. Attacking > these degradations one by one in a piecemeal manner is wasting time. We might as > well define the pass-ordering for Pre-IPO, IPO and Post-IPO phases...

Hi, Sean: I'm sorry I lie. I didn't mean to lie. I did try to avoid making a *BIG* change to the IPO pass-ordering for now. However, when I make a minor change to populateLTOPassManager() by separating module-pass and non-module-passes, I saw quite a few performance difference, most of them are degradations. Attacking these degradations one by one in a piecemeal manner is wasting time. We might as well define the pass-ordering for Pre-IPO, IPO and Post-IPO phases at this time...

Andy and I briefly discussed this the other day, we have not yet got chance to list a detailed pass order for the pre- and post- IPO scalar optimizations. This is wish-list in our mind: pre-IPO: based on the ordering he propose, get rid of the inlining (or just inline tiny func), get rid of all loop xforms... post-IPO: get rid of inlining, or maybe we still need it, only

...g <shuxin.llvm at gmail.com> > wrote: > > > Hi, Sean: > > > > I'm sorry I lie. I didn't mean to lie. I did try to avoid making > > a *BIG* change > > to the IPO pass-ordering for now. However, when I make a minor > > change to > > populateLTOPassManager() by separating module-pass and > > non-module-passes, I > > saw quite a few performance difference, most of them are > > degradations. Attacking > > these degradations one by one in a piecemeal manner is wasting > > time. We might as > > well define the pass-o...

...nline small functions if (RunInliner) PM.add(createFunctionInliningPass()); PM.add(createPruneEHPass()); // Remove dead EH info. if (RunInliner) PM.add(createGlobalOptimizerPass()); PM.add(createGlobalDCEPass()); // Remove dead functions. Then I looped over all LTO passes in the populateLTOPassManager() but adding them manually (incrementally, until I passed them all) didn't allow me to reproduce the error. I'll create a bugzilla for this, and the Clang warning. If Clang folks think it's worth, they can start from there. --renato On 8 January 2013 16:20, Duncan Sands <baldri...

...er my pass[2]. >> >> I've looked over the IR, but I can't see anything obviously wrong. >> >> I'm not sure what you meant by: >> >>> You may want to try to add it at the end of the pipeline >> >> My pass is the last one added inside populateLTOPassManager. Should I add it to the PassManager somewhere else? >> >> Thanks, >> Scott >> >> [1] https://gist.github.com/scottcarr/ce0bb6df1cbb44ec46a5 >> [2] http://pastebin.com/9xc2jpRj >> >> On 02/09/2016 01:36 PM, Mehdi Amini wrote: >>>> On F...

...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?). > > + if (!LTO) { > + // Remove avail extern fns and globals defini...

Hi Teresa, Impressive results, indeed! (But no less is expected from an Itanium alumni... ;-)) One question, if you don't mind. In the blog post you wrote: "In a few cases ThinLTO even outperforms full LTO, most likely because the higher scalability of ThinLTO allows using a more aggressive backend optimization pipeline (similar to that of a non-LTO build)." Is it due to

Hi Renato, On 08/01/13 17:16, Renato Golin wrote: > After looking at the Livermore for a while, we found the issue that was causing > LTO to produce a different result. > > Consider the code below [1]. setup() doesn't touch bar/baz, main() doesn't > reference foo. LTO finds, correctly, I don't think this is correct. At the LLVM IR level it is valid to write into bar

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,

After looking at the Livermore for a while, we found the issue that was causing LTO to produce a different result. Consider the code below [1]. setup() doesn't touch bar/baz, main() doesn't reference foo. LTO finds, correctly, that it can remove the setup(), but the result is different. The code is clearly wrong, but the compiler has no right to fix user's stupidity, even at that

....bc part3.o > -- > > 3) For demo purpose, I drive the post-IPO stage via a makefile, which encapsulate > hack and other nasty stuff. > > NOTE that the post-ipo pass in my hack contains only CodeGen pass, we need to > reorganize the PassManagerBuilder::populateLTOPassManager(), which intermingle > IPO pass along with intra-proc scalar pass, we need to separate them and the intra-proc > scalar pass to post-IPO stage. > > > 1 .PHONY = all > 2 > 3 > 4 BC = part1.bc part2.bc part3.bc > 5 OBJ = ${BC:.bc=.o} >...

...> -- > > 3) For demo purpose, I drive the post-IPO stage via a makefile, which > encapsulate > hack and other nasty stuff. > > NOTE that the post-ipo pass in my hack contains only CodeGen pass, > we need to > reorganize the PassManagerBuilder::**populateLTOPassManager(), which > intermingle > IPO pass along with intra-proc scalar pass, we need to separate them > and the intra-proc > scalar pass to post-IPO stage. > > > 1 .PHONY = all > 2 > 3 > 4 BC = part1.bc part2.bc part3.bc > 5 OBJ = ${B...

...2.bc part2.o part3.bc part3.o -- 3) For demo purpose, I drive the post-IPO stage via a makefile, which encapsulate hack and other nasty stuff. NOTE that the post-ipo pass in my hack contains only CodeGen pass, we need to reorganize the PassManagerBuilder::populateLTOPassManager(), which intermingle IPO pass along with intra-proc scalar pass, we need to separate them and the intra-proc scalar pass to post-IPO stage. 1 .PHONY = all 2 3 4 BC = part1.bc part2.bc part3.bc 5 OBJ = ${BC:.bc=.o} 6 7 all : merged...