similar to: [LLVMdev] noalias locals

On Sun, Nov 14, 2010 at 11:45 AM, Reid Kleckner <reid.kleckner at gmail.com> wrote: > On Sun, Nov 14, 2010 at 11:17 AM, Kenneth Uildriks <kennethuil at gmail.com> wrote: >> To fix that and compile C++ correctly while aggressively >> devirtualizing it, we would need to apply "noalias" to the result of >> placement-new in all cases, even when placement-new

On Sun, Nov 14, 2010 at 11:17 AM, Kenneth Uildriks <kennethuil at gmail.com> wrote: > To fix that and compile C++ correctly while aggressively > devirtualizing it, we would need to apply "noalias" to the result of > placement-new in all cases, even when placement-new is inlined.  More > generally, when inlining any function with a "noalias" return, the >

On Sun, Nov 14, 2010 at 2:37 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote: > On Sun, Nov 14, 2010 at 11:45 AM, Reid Kleckner <reid.kleckner at gmail.com> wrote: >> On Sun, Nov 14, 2010 at 11:17 AM, Kenneth Uildriks <kennethuil at gmail.com> wrote: >>> To fix that and compile C++ correctly while aggressively >>> devirtualizing it, we would need

On Oct 13, 2010, at 5:09 PM, Kenneth Uildriks wrote: > But I believe the language does allow "undefined behavior" if there's > a use of pT when the pointed-to object isn't actually of type T. It's > an invalid use in that case, right? Yes, but not for an arbitrary pointer which aliases pT. That's why it's a problem that llm.invariant is specified in terms

On Wed, Oct 13, 2010 at 6:49 PM, John McCall <rjmccall at apple.com> wrote: > > On Oct 13, 2010, at 4:35 AM, Kenneth Uildriks wrote: > >> On Wed, Oct 13, 2010 at 12:45 AM, Nick Lewycky <nicholas at mxc.ca> wrote: >>> Kenneth Uildriks wrote: >>>>> >>>>> You're right, I hadn't thought this through. The whole point of making

On Wed, Oct 13, 2010 at 7:26 PM, John McCall <rjmccall at apple.com> wrote: > On Oct 13, 2010, at 5:09 PM, Kenneth Uildriks wrote: >> But I believe the language does allow "undefined behavior" if there's >> a use of pT when the pointed-to object isn't actually of type T.  It's >> an invalid use in that case, right? > > Yes, but not for an

My understanding is that alias analysis returns results in the function scope, not in loop scope. Since both the phis access both global arrays, that should results in BasicAA conservatively returning MayAlias. I debugged this a little bit and narrowed it down to the section of the code in BasicAAResult::aliasPHI() which has this comment- // Analyse the PHIs' inputs under the assumption

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

Hi Hal, In that case what is the best way to query whether there is a loop carried dependence between B[j] and A[j] at i-loop level? We were operating under the assumption of 'conservatively correct' behavior of alias analysis in the function scope? Thanks, Pankaj From: Finkel, Hal J. <hfinkel at anl.gov> Sent: Tuesday, March 17, 2020 11:50 AM To: Hiroshi Yamauchi <yamauchi at

Updated testcases to have MayAlias/note issues as FIXME. On Tue Jan 20 2015 at 3:54:10 PM Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Daniel Berlin" <dberlin at dberlin.org> > > To: "Hal Finkel" <hfinkel at anl.gov> > > Cc: "Jiangning Liu" <Jiangning.Liu at arm.com>, "George

Hi! On 7/10/2020 07:17, Shuai Wang wrote: > Hello! > > Thank you very much! Yes, that makes a lot of sense to me. However, just > want to point out two things that are still unclear: > > 1. The output contains a alias set of only one element, for instance: > "must alias, Mod       Pointers: (i32* %y, LocationSize::precise(4))" > > This one really confused

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

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

Hello all, I observed that BasicAA alias query returns PartialAlias between different fields of a structure. Following is the test program and -print–all-alias-modref-info output: --- ; test.ll target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-unknown-linux-gnu" %"type" = type { [10 x i32], i64 } define void

----- Original Message ----- > From: "Daniel Berlin" <dberlin at dberlin.org> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Jiangning Liu" <Jiangning.Liu at arm.com>, "George Burgess IV" <george.burgess.iv at gmail.com>, "LLVM Developers > Mailing List" <llvmdev at cs.uiuc.edu>, "Nick Lewycky"

Works for me On Thu, Jan 22, 2015 at 8:27 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > We should use graph edges, so we can do something better at set build time > :) > > > On Thu Jan 22 2015 at 5:20:46 PM George Burgess IV < > george.burgess.iv at gmail.com> wrote: > >> > Should we be added an edge from the inttoptr to all other pointer >>

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

Hi all, I have this test case- #define N 1000 extern double Ag[N]; extern double Bg[N]; void consume(double *A, double *B); void swap_deps() { double *A = Ag; double *B = Bg; for (int i = 0; i < 97; ++i) { for (int j = 0; j < N; ++j) { B[j] = A[j] + 1; } double *tmp = A; A = B; B = tmp; } consume(A, B); } BasicAA is returning 'NoAlias' when

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

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