search for: setpreserveal

Hi, Devang Patel wrote: > 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

Hi James, Thanks for the help. From the log, I could infer that SLP vectorizer is not preserving alias analysis, preventing GVN from getting the info. Although the first function to get compiled has GlobalsAA available during GVN, rest of them do not as SLP vectorizer run on that function invalidates GlobalsAA which is a module pass. Is there a way to force re-computation of a particular

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?

Thank you both for the inputs. I've created a patch for the same, please review: http://reviews.llvm.org/D15185 >You can specifically insert it into the pass pipeline, but in this case, we should just fix SLP to preserve the analysis. @Hal, I tried doing this but it didn't seem to work. I added the GlobalsAA pass right before GVN but it didn't seem to help. In retrospect, looking

Hi Mehdi, Thank you for the response. I'm actually on an LTO setup and was referring to PassManagerBuilder::addLTOOptimizationPasses. Here, GlobalsAA is scheduled to run well ahead of SLPVectorizer. However since GlobalsAA is a module pass, it runs once and a bunch of passes, including SLPVectorizer is run for each function. When one of them invalidates the analysis, rest of the functions do

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  

>You could, in the LTO pipeline, reinsert GlobalsAA after the SLPVectorizer (not saying you should). I didn't realise that adding GlobalsAA* after* SLPVectorizer could help. Thanks for this tip. >There is something fishy. Do you have a test case that reproduce with llvm-lto? I'm currently looking at a proprietary benchmark. I'll try to extract out a simple test case and send it.

Hi. On 11/17/2009 08:16 PM, Andreas Neustifter wrote: > Hi, > > Devang Patel wrote: >> 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

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

On Wed, Jul 13, 2016 at 1:48 AM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Wed, Jul 13, 2016 at 12:34 AM, Chandler Carruth <chandlerc at gmail.com> > wrote: > >> On Wed, Jul 13, 2016 at 12:25 AM Sean Silva <chisophugis at gmail.com> >> wrote: >> >>> On Tue, Jul 12, 2016 at 11:39 PM, Chandler Carruth <chandlerc at

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

On Fri, Jul 15, 2016 at 8:39 PM, Sean Silva <chisophugis at gmail.com> wrote: > It looks like there is really no sane fix within the current > infrastructure. I've had to essentially trigger invalidation (except in the > PreservedAnalyses::all() case) in the function pass manager and function to > loop adapters. > invalidation of *everything* I mean. -- Sean Silva

Hi Sean, Thanks for writing all of this up. I'll go back to my previous position: we need a general dependency graph built as the analysis cache is used. It should have the following properties: 1. When we call getResult or getCachedResult on an analysis manager, we record a dependency of the current pass on the returned result. 2. This dependency needs to be stored such that it can be

----- Original Message ----- > From: "Sean Silva" <chisophugis at gmail.com> > To: "Chandler Carruth" <chandlerc at gmail.com> > Cc: "Xinliang David Li" <davidxl at google.com>, "llvm-dev" > <llvm-dev at lists.llvm.org>, "Davide Italiano" > <dccitaliano at gmail.com>, "Tim Amini Golling" >

----- Original Message ----- > From: "Mehdi Amini" <mehdi.amini at apple.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Sean Silva" <chisophugis at gmail.com>, "Xinliang David Li" > <davidxl at google.com>, "llvm-dev" <llvm-dev at lists.llvm.org>, "Davide > Italiano" <dccitaliano at

----- Original Message ----- > From: "Sean Silva" <chisophugis at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Xinliang David Li" <davidxl at google.com>, "llvm-dev" > <llvm-dev at lists.llvm.org>, "Davide Italiano" > <dccitaliano at gmail.com>, "Tim Amini Golling" >

We need better terminology to talk about this. I propose: analysis-dependencies: analysis A uses result of analysis B when *running* an analysis and not used by the result query-dependencies: result of analysis A uses result of analysis B when evaluating a query data-structure-depnedencies: result of analysis A uses data structures from the result of analysis B inside its own data structures I

The more closely I look at this, the more it seems like there may be a useful incremental step in the transition to the new PM: use the new PM analysis machinery in the old PM. If this is possible, it will simplify the old PM and (hopefully) allow an incremental transition to the new PM instead of a flag day transition for the switch. I.e., AFAICT, the new PM transition is essentially about 2

On Sun, Aug 7, 2016 at 4:55 PM, Philip Reames <listmail at philipreames.com> wrote: > Skimming the thread, this post is the clearest path forward I've seen. > Minor comments inline, but I generally like this framing. > > On 07/14/2016 08:04 PM, Chandler Carruth via llvm-dev wrote: > > We need better terminology to talk about this. I propose: > >

I'm not quite sure what post to respond to for a status update, but I guess this one will do (and you can check my log for more info of course). My current working branch for the analysis manager stuff is at https://github.com/chisophugis/llvm/commits/analysis-manager (4ecf6115890bd01caa52c0b99424974e3469291e) I described in my log a bit more my thought process and how to do this without