similar to: [LLVMdev] Pointer aliasing

Hi Roel, the code you list below is precisely what I expect to get (of course the stores must happen but the constant folding should happen as well). It all looks very strange. LLVM is behaving as if the __restrict__ keyword was not used at all. Even more strange is the fact that for this function: double f(double *__restrict__ x, double *__restrict__ y, double *__restrict__ z) { *x = 1.0;

Hi Brent, Looking at your code I can see at least one reason why some of the store operations remain in the output since you are (through x, y, and z) writing in memory which exists outside of your function (p). Constant propagation also seems to work in the first few lines, *y = *x +1 (%3) is stored directly. The strange thing to me is that the same doesn't happen for *z = *x + 2. Here

Can you explain please why it works for this version of the function: double f(double *__restrict__ x, double *__restrict__ y, double *__restrict__ z); What is different here? There are stores here as well. Brent On Wed, Jan 25, 2012 at 12:34 AM, Roel Jordans <r.jordans at tue.nl> wrote: > Hi Brent, > > I think this is a problem in the easy-cse transform. In this transform

I think the problem here is that the IR doesn't have any way to attach restrict information to loads/stores/pointers. It works on arguments because they can be given the 'noalias' attribute, and then the alias analyzer must understand what that means. Pete On Jan 24, 2012, at 7:47 AM, Roel Jordans wrote: > I have no clue, I didn't have time to look into that example yet.

Hi Brent, I think this is a problem in the easy-cse transform. In this transform load operations can be replaced by their subexpression, in this case the propagated constant, based on the value of the 'CurrentGeneration' of memory writes. This implies that any store operation invalidates the knowledge about previously stored subexpressions. In general, this is a safe assumption but

I have no clue, I didn't have time to look into that example yet. How does the IR (before optimization) differ from the other version? Roel On 01/24/2012 04:45 PM, Brent Walker wrote: > Can you explain please why it works for this version of the function: > > double f(double *__restrict__ x, double *__restrict__ y, double > *__restrict__ z); > > What is different here?

Peter Cooper wrote: > I think the problem here is that the IR doesn't have any way to attach restrict information to loads/stores/pointers. I think we do now, actually. Now that the loads and stores have TBAA metadata, I think the restrict attribute can go there. It needs to be attached to every use of a restrict pointer, but that's similar to how TBAA already works. > It works

Thank you for your reply. The compromise you describe below, is it a compromise in the LLVM back end or in clang? I run into this while building a compiler for a small DSL language for which I generate functions that receive a context from which they extract a bunch of pointers to doubles from which inputs are passed to the function (I just used C/clang in my examples to illustrate the problem).

Hi Brent, > Unless I can mark these extracted pointers as non-aliasing, performance > suffers a lot. It's not just CSE that suffers -- LLVM does not do > copy propagation either so we keep loading the same values from memory > over and over again. See the example here: > > double f(double a, double * x, double *y, double * z) > { > *x = a; > *y = a+1; >

Hi Duncan, you have misunderstood me I think. Of course in this case you have to reload the doubles since as you say the pointers may be aliasing each other. I just wrote it this way to show the kind of code one gets if one cannot specify that pointers do now alias -- not adding the __restrict__ to the function arguments gives the same code as in my example with the local variables (with or

On Jan 24, 2012, at 7:45 AM, Brent Walker wrote: > Can you explain please why it works for this version of the function: > > double f(double *__restrict__ x, double *__restrict__ y, double > *__restrict__ z); > > What is different here? There are stores here as well. LLVM ignores restrict everywhere except function parameters. This is a compromise aimed at a sweet spot in

On Jan 24, 2012, at 8:58 PM, Brent Walker wrote: > Thank you for your reply. The compromise you describe below, is it a > compromise in the LLVM back end or in clang? I run into this while > building a compiler for a small DSL language for which I generate > functions that receive a context from which they extract a bunch of > pointers to doubles from which inputs are passed to

Hi Dan and Others , I'm newbie to LLVM and Clang ,But has experience on compiler optimization and VM . Everyone talking about the LLVM in my organisation so thought of peeking into it and where this discussion is stalled me ... so i tried to simulate the problem ,which is discussed here . vi sample.c double f(double** p ) { double a,b,c; double * x = &a; double * y =

Hi I do not really understand why frontend generated TBAA metadata is needed for the TBAA pass to work. It seems to me that we can always go up the IR chain and find the base type from which the pointer is derived from. Take the following example. I know %0 = load i32, i32* %a, align 4, !tbaa !1 and store i32 %i.02, i32* %b, align 4, !tbaa !6 do not alias as their metadata !1 = !{!2, !3, i64

Can you send the IR you are using? Volkan On Thu, Oct 8, 2015 at 6:28 AM Erdem Derebaşoğlu < erdemderebasoglu at hotmail.com> wrote: > Thanks. I enabled my pass. I have one resolved issue though: > MachineMemOperand::getAddrSpace() always returns zero. How can I use it to > distinguish private memory accesses? > > Erdem > > ------------------------------ > From:

[AMD Official Use Only - Internal Distribution Only] Hi, Following issue is observed with Type Based Alias Analysis(TBAA). ####################################################### struct P { float f1; float f2; float f3[3]; float f4; }; void foo(struct P* p1, struct P* p2) { p1->f2 = 1.2; p2->f1 = 3.7; } int callFoo() { struct P p; foo(&p, &(p.f2)); }

----- Original Message ----- > From: "Chandler Carruth" <chandlerc at google.com> > To: "Zinovy Nis" <zinovy.nis at gmail.com> > Cc: "Hal Finkel" <hfinkel at anl.gov>, "James Molloy" <james at jamesmolloy.co.uk>, "LLVM Developers Mailing List" > <llvmdev at cs.uiuc.edu> > Sent: Thursday, October 16, 2014

To reproduce the issue, please use the command line "opt -simplifycfg filename". target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-unknown-linux-gnu" %struct.G = type { %struct.ordered_index_node*, i32 } %struct.ordered_index_node = type { %struct.B, %struct.F } %struct.B = type { i32 } %struct.F = type { i32*, i32* }

So I've been narrowing down a very fun issue in our Burst compiler stack with respect to noalias support, and I've managed to basically boil this down to the following failure (see https://godbolt.org/z/-mdjPV): int called(int* __restrict__ a, int* b, int* c) { return *a + *b + *c; } int foo(int * x, int * y) { return *x + *y + called(x, x, y); } int bar(int * x, int * y) { return

On Thu, Dec 8, 2011 at 2:11 PM, Vitor Luis Menezes <vitor at utexas.edu> wrote: > We've got the following test case: > > > class A { > public: >   int x; >   A(int x) : x(x) {} >   int hoo() {return 4;} >   virtual int foo() {return x;} >   virtual int goo() {return foo()+10;} >   virtual int operator+(A &a) { >     return x + a.x; >   } > };