similar to: [LLVMdev] [cfe-dev] no-alias generated as result of restrict function arguments

On Wed, Dec 12, 2012 at 8:38 AM, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: > On Tue, Dec 11, 2012 at 03:17:43AM -0800, Chandler Carruth wrote: >> As Joerg pointed out in IRC, 'y' is an lvalue, but we do not use it to >> access the object it designates, we only use it to compute the address, and >> thus restrict should have no bearing on it. That

On Wed, Dec 12, 2012 at 11:01:01AM -0800, Dan Gohman wrote: > > Is that > > assumption violated if I explicitly cast away const and pass the result > > to a function with NoAlias argument? > > Not immediately, no. It means that you can't access the constant > pointer's pointee directly within the noalias argument's scope. Access > to that object must go

On Wed, Dec 12, 2012 at 1:26 PM, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: > On Wed, Dec 12, 2012 at 11:01:01AM -0800, Dan Gohman wrote: >> > Is that >> > assumption violated if I explicitly cast away const and pass the result >> > to a function with NoAlias argument? >> >> Not immediately, no. It means that you can't access the

On Wed, Dec 12, 2012 at 01:59:55PM -0800, Dan Gohman wrote: > The bug here isn't in clang's use of noalias or in BasicAliasAnalysis' > implementation of noalias; it's in the code that's optimizing the > icmp. Let's come back to this. The attached patch decouples InstSimplify from the alias analysis and provides the conservative logic for when pointers are not

After discussing with Nick Lewycky in the IRC channel, here comes a less aggressive patch. We were worried that a constant pointer could alias with a GlobalValue. Also, if one pointer could be a GlobalValue and the other a GlobalAlias with the GlobalValue as aliasee. However, I was not able to produce a test where this happens wihout the getUnderlyingObject() returning the same value. It

On Nov 4, 2009, at 6:43 AM, Hans Wennborg wrote: > Here is another change I'd like to suggest to the BasicAliasAnalysis. > > LLVM fails to remove the dead store in the following code: > > %t = type { i32 } > > define void @f(%t* noalias nocapture %stuff ) { > %p = getelementptr inbounds %t* %stuff, i32 0, i32 0 > > store i32 1, i32* %p; <-- This

Hans Wennborg wrote: > After discussing with Nick Lewycky in the IRC channel, here comes a less > aggressive patch. > > We were worried that a constant pointer could alias with a GlobalValue. > Also, if one pointer could be a GlobalValue and the other a GlobalAlias > with the GlobalValue as aliasee. > However, I was not able to produce a test where this happens wihout the

Dan Gohman wrote: > On Nov 4, 2009, at 6:43 AM, Hans Wennborg wrote: > >> Here is another change I'd like to suggest to the BasicAliasAnalysis. >> >> LLVM fails to remove the dead store in the following code: >> >> %t = type { i32 } >> >> define void @f(%t* noalias nocapture %stuff ) { >> %p = getelementptr inbounds %t* %stuff, i32 0,

On Wed, Dec 12, 2012 at 2:45 PM, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: > On Wed, Dec 12, 2012 at 01:59:55PM -0800, Dan Gohman wrote: >> On Wed, Dec 12, 2012 at 1:26 PM, Joerg Sonnenberger >> > The original issue is that clang maps restrict on function arguments to >> > NoAlias and that makes compares against the address of global variables >>

On Wed, Dec 12, 2012 at 01:59:55PM -0800, Dan Gohman wrote: > On Wed, Dec 12, 2012 at 1:26 PM, Joerg Sonnenberger > > The original issue is that clang maps restrict on function arguments to > > NoAlias and that makes compares against the address of global variables > > false. Minimal test case: > > > > @y = external global i32 > > > > define zeroext i1

Regarding the name, I'm not sure noaliasAtFunctionEntry makes sense, for two reasons: a) The pointer involved may not be defined at entry. b) We already have something which is similar in spirit - IsIdentifiedObject. That covers the 3 cases I have in the new function, but also two additional ones: GlobalValues which are not GlobalAliases, and byval arguments. Unfortunately, a check of

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

Kuperstein, Michael M wrote: > Regarding the name, I'm not sure noaliasAtFunctionEntry makes sense, for two reasons: > a) The pointer involved may not be defined at entry. Right, I thought of that too. > b) We already have something which is similar in spirit - IsIdentifiedObject. That covers the 3 cases I have in the new function, but also two additional ones: GlobalValues which

Here is another change I'd like to suggest to the BasicAliasAnalysis. LLVM fails to remove the dead store in the following code: %t = type { i32 } define void @f(%t* noalias nocapture %stuff ) { %p = getelementptr inbounds %t* %stuff, i32 0, i32 0 store i32 1, i32* %p; <-- This store is dead %x = load i32* inttoptr (i32 12345 to i32*) store i32 %x, i32* %p ret

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

On Wed, Jan 16, 2013 at 12:53:55AM +0100, Joerg Sonnenberger wrote: > Let's come back to this. The attached patch decouples InstSimplify from > the alias analysis and provides the conservative logic for when pointers > are not equal. Let's take the version with the cleanup from IRC. *sigh* Dealing with too many copies. Joerg -------------- next part -------------- Index:

Kuperstein, Michael M wrote: > Thanks Nick! > > Can you just check sanity before I commit? > (Or suggest a better name for the function...) Sure! +static bool canNotAliasDiffArgument(const Value *V) +{ + return (isa<AllocaInst>(V) || isNoAliasCall(V) || isNoAliasArgument(V)); +} Extra parens? The name "canNotAliasDiffArgument" works, but it's named for what we

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

----- Original Message ----- > From: "Daniel Berlin" <dberlin at dberlin.org> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Chandler Carruth" <chandlerc at google.com>, "Clang Developers" <cfe-dev at cs.uiuc.edu>, "LLVM Developers Mailing > List" <llvmdev at cs.uiuc.edu> > Sent: Monday, December 3, 2012

On Mon, Dec 3, 2012 at 6:19 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Daniel Berlin" <dberlin at dberlin.org> >> To: "Hal Finkel" <hfinkel at anl.gov> >> Cc: "Chandler Carruth" <chandlerc at google.com>, "Clang Developers" <cfe-dev at cs.uiuc.edu>, "LLVM