search for: addinitialaliasanalysispasses

...ata structures that have lots of derived pointers and we use extensive tbaa metadata to indicate which pointers dont alias. Some of this seemed to be getting ignored in 3.0. I found by using opt on our IR that the ordering of the basicaa and tbaa optimization passes made all the difference. Code in addInitialAliasAnalysisPasses() adds the tbaa pass then basicaa pass. From Chris' comments in the forum about backward chaining of alais analysis that would execute basicaa before tbaa - and that would have the effect of basicaa doing the first pass of analysis followed by tbaa, possibly overriding the "wont alias&quot...

...ata structures that have lots of derived pointers and we use extensive tbaa metadata to indicate which pointers dont alias. Some of this seemed to be getting ignored in 3.0. I found by using opt on our IR that the ordering of the basicaa and tbaa optimization passes made all the difference. Code in addInitialAliasAnalysisPasses() adds the tbaa pass then basicaa pass. From Chris' comments in the forum about backward chaining of alais analysis that would execute basicaa before tbaa - and that would have the effect of basicaa doing the first pass of analysis followed by tbaa, possibly overriding the "wont alias&quot...

...lots of > derived pointers and we use extensive tbaa metadata to indicate which > pointers dont alias. Some of this seemed to be getting ignored in 3.0. I > found by using opt on our IR that the ordering of the basicaa and tbaa > optimization passes made all the difference. Code in > addInitialAliasAnalysisPasses() adds the tbaa pass then basicaa pass. From > Chris' comments in the forum about backward chaining of alais analysis that > would execute basicaa before tbaa - and that would have the effect of > basicaa doing the first pass of analysis followed by tbaa, possibly > overriding the &...

Hi, In lib/Transforms/IPO/PassManagerBuilder.cpp: addInitialAliasAnalysisPasses, I see this code ------ // Add TypeBasedAliasAnalysis before BasicAliasAnalysis so that // BasicAliasAnalysis wins if they disagree. This is intended to help // support "obvious" type-punning idioms. PM.add(createTypeBasedAliasAnalysisPass()); PM.add(createBasicAliasAnalysisPass...

...Wont alias" when we know that the pointers will never alias. So its not covered by your case. Since the basicaa pass doesnt chain according to the llvm docs, it should have the last chance to affect the aliasing information, and that means it should be added first. If so the existing code in addInitialAliasAnalysisPasses has them round the wrong way. On Sat, Jan 28, 2012 at 10:46 AM, Maurice Marks <maurice.marks at gmail.com>wrote: > Many of our pointers point into a structure where they could be considered > as having the same base address. We use tbaa to indicate which ones could > or could not a...

...ata structures that have lots of derived pointers and we use extensive tbaa metadata to indicate which pointers dont alias. Some of this seemed to be getting ignored in 3.0. I found by using opt on our IR that the ordering of the basicaa and tbaa optimization passes made all the difference. Code in addInitialAliasAnalysisPasses() adds the tbaa pass then basicaa pass. From Chris' comments in the forum about backward chaining of alais analysis that would execute basicaa before tbaa - and that would have the effect of basicaa doing the first pass of analysis followed by tbaa, possibly overriding the "wont alias&quot...

Hi Pranav, > In lib/Transforms/IPO/PassManagerBuilder.cpp: addInitialAliasAnalysisPasses, > I see this code > ------ > // Add TypeBasedAliasAnalysis before BasicAliasAnalysis so that > // BasicAliasAnalysis wins if they disagree. This is intended to help > // support "obvious" type-punning idioms. > PM.add(createTypeBasedAliasAnalysisPass()); &gt...

...mer to write code that violates > these rules (That's why we have -fno-strict-aliasing). > So when basica gives up returning mayalias we query tbaa, which will return - > based on strict aliasing rules of our language - noalias. Except... TBAA is called prior to basicaa, when using addInitialAliasAnalysisPasses(). - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.

BasicAA treats it conservatively if used on its own. It will return mayalias for the two pointers. TBAA operates based on the guarantee that pointers to different types cannot alias (think C's strict aliasing rules). Therein lies its power but also its danger, that is, nothing prevents the programmer to write code that violates these rules (That's why we have -fno-strict-aliasing). So

...the always-inline pass. + if (OptLevel == 0) { + if (Inliner) { + MPM.add(Inliner); + Inliner = 0; + } + return; + } + + bool EnableLightWeightIPO = (OptLevel > 1); + + // Add LibraryInfo if we have some. + if (LibraryInfo) MPM.add(new TargetLibraryInfo(*LibraryInfo)); + addInitialAliasAnalysisPasses(MPM); + + // Start of CallGraph SCC passes. + { + if (EnableLightWeightIPO) { + MPM.add(createPruneEHPass()); // Remove dead EH info + if (Inliner) { + MPM.add(Inliner); + Inliner = 0; + } + MPM.add(createArgumentPromotionPass()); // Scalarize un...

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

On Thu, Jan 15, 2015 at 1:26 PM, Nick Lewycky <nlewycky at google.com> wrote: > On 15 January 2015 at 13:10, Daniel Berlin <dberlin at dberlin.org> wrote: > >> Yes. >> I've attached an updated patch that does the following: >> >> 1. Fixes the partialalias of globals/arguments >> 2. Enables partialalias for cases where nothing has been unified to

----- Original Message ----- > From: "Daniel Berlin" <dberlin at dberlin.org> > To: "Jingyue Wu" <jingyue at google.com> > Cc: "Hal Finkel" <hfinkel at anl.gov>, llvm-dev at lists.llvm.org, "Justin Holewinski" <jholewinski at nvidia.com> > Sent: Wednesday, August 12, 2015 2:03:34 PM > Subject: Re: [llvm-dev] [RFC]

...rifier to determine if the input diff --git a/lib/Transforms/IPO/PassManagerBuilder.cpp b/lib/Transforms/IPO/PassManagerBuilder.cpp index bb776ef..645686c 100644 --- a/lib/Transforms/IPO/PassManagerBuilder.cpp +++ b/lib/Transforms/IPO/PassManagerBuilder.cpp @@ -132,10 +132,10 @@ PassManagerBuilder::addInitialAliasAnalysisPasses(PassManagerBase &PM) const { // Add TypeBasedAliasAnalysis before BasicAliasAnalysis so that // BasicAliasAnalysis wins if they disagree. This is intended to help // support "obvious" type-punning idioms. - if (UseCFLAA) - PM.add(createCFLAliasAnalysisPass()); PM.add(c...

Oh, sorry, i didn't rebase it when i changed the fix, you would have had to apply the first on top of the second. Here is one against HEAD On Wed, Jan 14, 2015 at 12:32 PM, Ana Pazos <apazos at codeaurora.org> wrote: > Daniel, your patch does not apply cleanly. Are you on the tip? > > The code I see there is no line if (QueryResult == MayAlias|| QueryResult == PartialAlias)