similar to: [LLVMdev] tbaa differences in llvm 3.0

On Jan 27, 2012, at 4:15 PM, Maurice Marks wrote: > Our application generates IR that is used to generate X86_64 code for a Jit. We noticed that code generated with llvm 3.0 is worse in some circumstances that it was with 2.9. I traced the differences to alias analysis differences. Our IR references data structures that have lots of derived pointers and we use extensive tbaa metadata to

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 alias because they are pointing into different substructures. This is exactly the sort of requirement that invoked the need for the restrict modifier in g++, c++0x etc. If I understand you correctly that cannot be expressed in llvm ir

On Fri, 2012-01-27 at 16:46 -0800, Dan Gohman wrote: > On Jan 27, 2012, at 4:15 PM, Maurice Marks wrote: > > > Our application generates IR that is used to generate X86_64 code for a Jit. We noticed that code generated with llvm 3.0 is worse in some circumstances that it was with 2.9. I traced the differences to alias analysis differences. Our IR references data structures that have

In our case basicaa alone returns "may alias" on our pointers and we want to override that with tbaa data to "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

Hello, I'm trying to get the whole picture of what we are doing in terms of alias analysis in LLVM. Being new to this I may be missing some well known things so my apologies if I seem to ask obvious things. There are lots of questions arise in my head as I read related bug reports, sources and documentation, of which looks to be the most simple is, Why the current TBAA implementation

(sorry for the wide distribution, but this impacts Clang users quite a bit) It's come up a few times in reviews of CFL-AA (a new alias analysis for LLVM), so I wanted to write down what I think the current state actually is for AA pass ordering, why, and how it should look eventually. I may have some bugs here, so please correct me if I miss anything. And I'd love thoughts about the end

Hi, I am observing some incorrect behavior in basicaa, wherein two pointers that basicaa should determine to be MustAlias are ending up NoAlias - the other extreme :( I am blaming this on basicaa not handling inttoptr. Here is the relevant IR snippet. -------------------- %sunkaddr36 = ptrtoint %struct.BitParams* %bs to i32 %sunkaddr37 = add i32 %sunkaddr36, 16 %sunkaddr38 = inttoptr i32

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Arnold Schwaighofer > Subject: [LLVMdev] inttoptr and basicaa > 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

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

Hello, After discussions with Daniel, Dan and others, here is an updated proposal for struct-access-path aware TBAA. Given an example struct A { int x; int y; }; struct B { A a; int z; }; struct C { B b1; B b2; int *p; }; struct D { C c; }; The purpose of struct-path-aware TBAA is to say "C::b1.a" will alias with "B::a.x", "C::b1.a" will alias with

So, I can make all these testcases work, but it's a little tricky (it involves tracking some things, like GEP byte range, and then checking bases and using getObjectSize, much like BasicAA does). Because i really don't want to put that much "not well tested" code in a bugfix, and honestly, i'm not sure we will catch any cases here that BasicAA does not, i've attached a

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)

Can you send me actual LLVM IR or a preprocessed source from using -E? I don't have a machine handy that has headers that target that arch. On Tue Jan 13 2015 at 4:33:29 PM Daniel Berlin <dberlin at dberlin.org> wrote: > Anything other than noalias or mustalias should be getting passed down the > stack, so either that is not happening or CFL aa is giving better answers > and

Without the patch is also returns the wrong answer for all of these, it just doesn't cause LICM to promote because it returns PartialAlias (which is still wrong). We return may-alias instead, and now suddenly it's happy to promote them. The broken noalias results exist both before and after my patch: ===== Alias Analysis Evaluator Report ===== 521 Total Alias Queries Performed

Inline - George > On Jan 14, 2015, at 10:49 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > >> On Tue, Jan 13, 2015 at 11:26 PM, Nick Lewycky <nlewycky at google.com> wrote: >>> On 13 January 2015 at 22:11, Daniel Berlin <dberlin at dberlin.org> wrote: >>> This is caused by CFLAA returning PartialAlias for a query that BasicAA can

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 a global/argument 3. Fixes that select was unifying the condition to the other pieces (the condition does not need to be processed :P). This was causing unnecessary aliasing. 4. Adds a regression test to

No, i mean the actual store instruction looks like "store i16 %conv22, i16* getelementptr inbounds ([16 x i16]* @pA, i64 0, i64 12), align 2, !tbaa !1" Not that the pointer operand comes from a GEP, but it is a constantexpr, whose opcode is GEP. It sucks that there is such a complex thing to be handled as a store operand directly , but such is life ... CFL-AA *should* treat this

On 13 January 2015 at 22:11, Daniel Berlin <dberlin at dberlin.org> wrote: > This is caused by CFLAA returning PartialAlias for a query that BasicAA > can prove is NoAlias. > One of them is wrong. Which one? I'm not sure from your description that this is a chaining issue. PartialAlias doesn't chain and isn't supposed to, it's a final answer just like NoAlias and

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()); } ------ My

Hi folks, Moving the discussion to llvm.dev. None of the changes we talked earlier help. Find attached the C source code that you can use to reproduce the issue. clang --target=aarch64-linux-gnu -c -mcpu=cortex-a57 -Ofast -fno-math-errno test.c -S -o test.s -mllvm -debug-only=licm LICM hoisting to while.body.lr.ph: %21 = load double** %arrayidx8, align 8, !tbaa !5 LICM hoisting to