similar to: [LLVMdev] Meaning of the nocapture attribute (possible bug?)

Regarding the nocapture attribute the language ref says: "the callee does not make any copies of the pointer that outlive the callee itself". >From I inferred that it is OK for the callee to make a copy of the pointer that doesn't outlive the call. However if I write some code that does this the optimizers don't do what I'd expect. Consider the following the example:

Hi Richard, I think it is a bug. Ciao, Duncan. On 08/10/12 14:34, Richard Osborne wrote: > Regarding the nocapture attribute the language ref says: "the callee does not > make any copies of the pointer that outlive the callee itself". From I inferred > that it is OK for the callee to make a copy of the pointer that doesn't outlive > the call. However if I write some

Hi Krzysztof, > Is this code valid? yes, I think so. > Function f takes a "nocapture" pointer p, and passes it to function g that does > not have nocapture in its parameter list. There is nothing to stop g from > "capturing" p. It would be wrong for the optimizers to deduce a nocapture attribute for f in this context, as they don't know anything about the

Is this code valid? Function f takes a "nocapture" pointer p, and passes it to function g that does not have nocapture in its parameter list. There is nothing to stop g from "capturing" p. -Krzysztof On 10/8/2012 8:54 AM, Duncan Sands wrote: > Hi Richard, I think it is a bug. > > Ciao, Duncan. > > On 08/10/12 14:34, Richard Osborne wrote: >>

<div>Need help about Alias Analysis.</div><div>I try to detect use-after-free debug in source code. And my analysis is based on LLVM IR.</div><div>I use the following code as a small example. I want to get the result p&&q are alias.</div><div>//uaf.cpp</div><div><div>#include<iostream></div><div>using namespace

Hi, I have a question about semantics of nocapture attribute: "This indicates that the callee does not make any copies of the pointer that outlive the callee itself. " Is returing a pointer considered outliving callee? For example is this code valid: define i8* @foo(i8* nocapture %p) ret i8* %p } The documentation also mention that " This is not a valid attribute for return

Thanks guys. Do you it make sense to extend the definition in LangRef? If so I will be happy to upload a patch. Piotr 2017-04-28 17:58 GMT+02:00 Hal Finkel <hfinkel at anl.gov>: > > > On 04/28/2017 10:22 AM, Piotr Padlewski via llvm-dev wrote: > > Hi, > I have a question about semantics of nocapture attribute: > "This indicates that the callee does not make any

On 12/5/18 9:51 AM, Andrew Savonichev via llvm-dev wrote: >> Hi, >> >> I'm trying to get AA results for two pointers, but it seems that AA >> cannot look though a memcpy. For example: >> >> define dso_local spir_func void @fun() { >> entry: >> ; Store an address of `var' >> %var = alloca i32, align 4 >>

Hi, I'm trying to get AA results for two pointers, but it seems that AA cannot look though a memcpy. For example: define dso_local spir_func void @fun() { entry: ; Store an address of `var' %var = alloca i32, align 4 store i32 42, i32* %var, align 4 %var.addr = alloca i32*, align 8 store i32* %var, i32** %var.addr, align 8 ; Memcpy

On 12/5/18 2:14 PM, Andrew Savonichev wrote: >> On 12/5/18 9:51 AM, Andrew Savonichev via llvm-dev wrote: >>>> Hi, >>>> >>>> I'm trying to get AA results for two pointers, but it seems that AA >>>> cannot look though a memcpy. For example: >>>> >>>> define dso_local spir_func void @fun() { >>>>

Hi I have this simple c code for which I would like to use for alias analysis. #include <stdio.h> #include <stdlib.h> static int (*fp) (void); void ind_call (int (*compr)(void)){ fp = compr; fp(); } int hello(void){ return printf("hello world\n"); } int main(){ ind_call(hello); return 0; } So, I do the following: bin/opt -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 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

[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)); }

Hi, I have the following C loop to vectorize: struct box { double* source; }; void test(double* restrict result, struct box my_struct, int len) { for (int i=0 ; i<len; i++) { result[i] = my_struct.source[i] * my_struct.source[i]; } } There are two references in the loop, result[i] (restrict) and my_struct.source[i] (readonly). The compiler should easily figure out that

On Sun, Mar 15, 2015 at 4:34 PM Olivier Sallenave <ol.sall at gmail.com> wrote: > Hi Daniel, > > Thanks for your feedback. I would prefer not to write a new AA. Can't we > directly implement that traversal in BasicAA? > Can I ask why? Outside of the "well, it's another pass", i mean? BasicAA is stateless, so you can't cache, and you really don't

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

On Fri, Mar 13, 2015 at 2:54 PM Daniel Berlin <dberlin at dberlin.org> wrote: > On Fri, Mar 13, 2015 at 2:39 PM Olivier H Sallenave <ohsallen at us.ibm.com> > wrote: > >> Hi, >> >> I have the following C loop to vectorize: >> >> struct box { >> double* source; >> }; >> >> void test(double* restrict result, struct box

Hey all, I was doing some investigation of LICM and I ran into something that seems a bit odd to me. Suppose I was looking at the following code snippet: #define N 1000 int main() { int B[N]; char A[N]; for(int i=0; i<N; i++) { B[i] = strlen(A); } return B[0]+B[N-1]; } Among other optimizations that I may want to happen, I'd hope that the call to strlen could be

Hi, Your problem is that the function arguments, which are makes as noalias, are not being directly used as the base objects of the array accesses: > %v0.addr = alloca float*, align 8 > %v1.addr = alloca float*, align 8 > %v2.addr = alloca float*, align 8 > %t.addr = alloca float*, align 8 ... > store float* %v0, float** %v0.addr, align 8 > store float* %v1, float** %v1.addr,

[AMD Public Use] Hi Oliver, I get rid of the warnings by explicitly type-casting it to struct*, and still get similar results. ####################################################### 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,