search for: setpreserv

...39; on Function 'main'... >> > 0x1c301a0 Executing Pass 'Dominator Tree Construction' on Function 'main'... > ... > > Did you update all these function passes to preserve profile info ? Ja, they are all either PreserveAll or I have updated them to AU.setPreserved<ProfileInfo>(). Andi

...jamesmolloy.co.uk> wrote: > Hi Vaivaswatha, > > GlobalsAA is not an immutable pass because it needs to cache queries to > avoid them being unusably slow. It therefore relies on passes explicitly > preserving it. Most of the passes in the scalar pipeline have been modified > to setPreserved<GlobalsAA>() and I know the pass gets preserved at least > until LICM. > > You can use -debug-pass=Executions to determine at what point GlobalsAA is > not preserved (which pass clobbers it) - you'd then need to add GlobalsAA > to its preserved pass list. > > Cheers...

Hi, I've noticed that alias analysis queries arising from GVN do not use the results from GlobalsAA. The last call to AAResultsWrapperPass::runOnFunction() before GVN does not add GlobalsAAWrapperPass due to unavailability. This leads to the alias queries from GVN not having any globals mod-ref info. Is this a known issue? and is there any way to have globals mod-ref info available for GVN?

...Hi Vaivaswatha, > > > > > > GlobalsAA is not an immutable pass because it needs to cache queries > > to avoid them being unusably slow. It therefore relies on passes > > explicitly preserving it. Most of the passes in the scalar pipeline > > have been modified to setPreserved<GlobalsAA>() and I know the pass > > gets preserved at least until LICM. > > > > > > You can use -debug-pass=Executions to determine at what point > > GlobalsAA is not preserved (which pass clobbers it) - you'd then > > need to add GlobalsAA to its pr...

...> >> > >> > GlobalsAA is not an immutable pass because it needs to cache queries >> > to avoid them being unusably slow. It therefore relies on passes >> > explicitly preserving it. Most of the passes in the scalar pipeline >> > have been modified to setPreserved<GlobalsAA>() and I know the pass >> > gets preserved at least until LICM. >> > >> > >> > You can use -debug-pass=Executions to determine at what point >> > GlobalsAA is not preserved (which pass clobbers it) - you'd then >> > need to...

On Tue, Nov 17, 2009 at 9:03 AM, Andreas Neustifter <astifter-llvm at gmx.at> wrote: > > Okay, so the ProfileInfoLoader is working, but when I examine the executions more closely I see that the ProfileInfo generated by the ProfileInfoLoader is immediately discarded, when the SelectionDAGISel kicks in the "No Profile Info"-Implementation is used: > >  > 0x1c1a740  

...gt; >>> > GlobalsAA is not an immutable pass because it needs to cache queries >>> > to avoid them being unusably slow. It therefore relies on passes >>> > explicitly preserving it. Most of the passes in the scalar pipeline >>> > have been modified to setPreserved<GlobalsAA>() and I know the pass >>> > gets preserved at least until LICM. >>> > >>> > >>> > You can use -debug-pass=Executions to determine at what point >>> > GlobalsAA is not preserved (which pass clobbers it) - you'd then &...

..... >>> > 0x1c301a0 Executing Pass 'Dominator Tree Construction' on Function 'main'... >> ... >> >> Did you update all these function passes to preserve profile info ? > > Ja, they are all either PreserveAll or I have updated them to > AU.setPreserved<ProfileInfo>(). So I have tried this for some days now, I don't get it: If I use AU.addRequired<ProfileInfo>() in SelectionDAGISel.cpp the wrong ProfileInfo is used. It uses the "No ProfileInfo" implementation if ProfileInfo but not the one from ProfileInfoLoaderPas...

Greetings folks! I would like to enable globalsmodref-aa in the non-LTO pass pipeline so that it gets tested more and there are fewer differences between the two. For all of my benchmarks, this is performance neutral, but I'd appreciate others benchmarking this combination to see if they see any benefits or regressions. You can demo this mode easily: -mllvm -enable-non-lto-gmr Please let me

...doesn't have the right semantics for even an error-prone solution :( We are going to need to make some significant changes to even get basic sanity I think. Perhaps each analysis can expose a "preserve" static function. E.g. instead of `PA.preserve<Foo>();` you have to do `Foo::setPreserved(PA);`. I'm actually not quite sure that that will even work. Once I have test-suite fully building successfully with the LTO pipeline in the new PM I'll be able to give a more confident answer (esp. w.r.t. the manager for different IRUnitT's). But at this point I'm not confident r...

Hi, I have trouble making my ProfileInfo-Analysis available in the backend, I have changed llc so it loads the ProfileInfo if requested, the PassManger gives this output: > Target Data Layout > Create Garbage Collector Module Metadata > Basic Alias Analysis (default AA impl) > DWARF Information Writer > No Profile Information > Module Information > ModulePass

...s for >> even an error-prone solution :( We are going to need to make some >> significant changes to even get basic sanity I think. Perhaps each analysis >> can expose a "preserve" static function. E.g. instead of >> `PA.preserve<Foo>();` you have to do `Foo::setPreserved(PA);`. >> I'm actually not quite sure that that will even work. Once I have >> test-suite fully building successfully with the LTO pipeline in the new PM >> I'll be able to give a more confident answer (esp. w.r.t. the manager for >> different IRUnitT's). >&...

...r > > even an error-prone solution :( We are going to need to make some > > significant changes to even get basic sanity I think. Perhaps each > > analysis can expose a "preserve" static function. E.g. instead of > > `PA.preserve<Foo>();` you have to do `Foo::setPreserved(PA);`. > > > I'm actually not quite sure that that will even work. Once I have > > test-suite fully building successfully with the LTO pipeline in the > > new PM I'll be able to give a more confident answer (esp. w.r.t. > > the > > manager for different I...

...t; some > > > > significant changes to even get basic sanity I think. Perhaps > > > > each > > > > analysis can expose a "preserve" static function. E.g. instead > > > > of > > > > `PA.preserve<Foo>();` you have to do `Foo::setPreserved(PA);`. > > > > > > > > > > I'm actually not quite sure that that will even work. Once I > > > > have > > > > test-suite fully building successfully with the LTO pipeline in > > > > the > > > > new PM I'll be...

...t; some > > > > significant changes to even get basic sanity I think. Perhaps > > > > each > > > > analysis can expose a "preserve" static function. E.g. instead > > > > of > > > > `PA.preserve<Foo>();` you have to do `Foo::setPreserved(PA);`. > > > > > > > > > > I'm actually not quite sure that that will even work. Once I > > > > have > > > > test-suite fully building successfully with the LTO pipeline in > > > > the > > > > new PM I'll be...

...t; some > > > > significant changes to even get basic sanity I think. Perhaps > > > > each > > > > analysis can expose a "preserve" static function. E.g. instead > > > > of > > > > `PA.preserve<Foo>();` you have to do `Foo::setPreserved(PA);`. > > > > > > > > > > I'm actually not quite sure that that will even work. Once I > > > > have > > > > test-suite fully building successfully with the LTO pipeline in > > > > the > > > > new PM I'll be...

...t; even an error-prone solution :( We are going to need to make some >>> significant changes to even get basic sanity I think. Perhaps each analysis >>> can expose a "preserve" static function. E.g. instead of >>> `PA.preserve<Foo>();` you have to do `Foo::setPreserved(PA);`. >>> I'm actually not quite sure that that will even work. Once I have >>> test-suite fully building successfully with the LTO pipeline in the new PM >>> I'll be able to give a more confident answer (esp. w.r.t. the manager for >>> different IRUni...

...rror-prone solution :( We are going to need to make some >>>> significant changes to even get basic sanity I think. Perhaps each analysis >>>> can expose a "preserve" static function. E.g. instead of >>>> `PA.preserve<Foo>();` you have to do `Foo::setPreserved(PA);`. >>>> I'm actually not quite sure that that will even work. Once I have >>>> test-suite fully building successfully with the LTO pipeline in the new PM >>>> I'll be able to give a more confident answer (esp. w.r.t. the manager for >>>>...

...rror-prone solution :( We are going to need to make some >>>> significant changes to even get basic sanity I think. Perhaps each analysis >>>> can expose a "preserve" static function. E.g. instead of >>>> `PA.preserve<Foo>();` you have to do `Foo::setPreserved(PA);`. >>>> I'm actually not quite sure that that will even work. Once I have >>>> test-suite fully building successfully with the LTO pipeline in the new PM >>>> I'll be able to give a more confident answer (esp. w.r.t. the manager for >>>>...

...e are going to need to make some >>>>>> significant changes to even get basic sanity I think. Perhaps each analysis >>>>>> can expose a "preserve" static function. E.g. instead of >>>>>> `PA.preserve<Foo>();` you have to do `Foo::setPreserved(PA);`. >>>>>> I'm actually not quite sure that that will even work. Once I have >>>>>> test-suite fully building successfully with the LTO pipeline in the new PM >>>>>> I'll be able to give a more confident answer (esp. w.r.t. the mana...