Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] [cfe-dev] no-alias generated as result of restrict function arguments"
2012 Dec 12
0
[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
2012 Dec 12
3
[LLVMdev] [cfe-dev] no-alias generated as result of restrict function arguments
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
2012 Dec 12
0
[LLVMdev] [cfe-dev] no-alias generated as result of restrict function arguments
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
2013 Jan 15
2
[LLVMdev] [cfe-dev] no-alias generated as result of restrict function arguments
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
2009 Nov 12
0
[LLVMdev] BasicAliasAnalysis: constant does not alias with noalias parameter
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
2009 Nov 05
0
[LLVMdev] BasicAliasAnalysis: constant does not alias with noalias parameter
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
2009 Nov 13
1
[LLVMdev] BasicAliasAnalysis: constant does not alias with noalias parameter
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
2009 Nov 10
4
[LLVMdev] BasicAliasAnalysis: constant does not alias with noalias parameter
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,
2012 Dec 13
0
[LLVMdev] [cfe-dev] no-alias generated as result of restrict function arguments
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
>>
2012 Dec 12
2
[LLVMdev] [cfe-dev] no-alias generated as result of restrict function arguments
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
2013 May 27
0
[LLVMdev] Mixing noalias and regular arguments
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
2015 Mar 13
2
[LLVMdev] Alias analysis issue with structs on PPC
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
2013 May 27
1
[LLVMdev] Mixing noalias and regular arguments
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
2009 Nov 04
2
[LLVMdev] BasicAliasAnalysis: constant does not alias with noalias parameter
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
2015 Mar 15
5
[LLVMdev] Alias analysis issue with structs on PPC
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
2013 Jan 16
0
[LLVMdev] [cfe-dev] no-alias generated as result of restrict function arguments
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:
2013 May 27
2
[LLVMdev] Mixing noalias and regular arguments
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
2015 Mar 13
2
[LLVMdev] Alias analysis issue with structs on PPC
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
2012 Dec 03
2
[LLVMdev] [RFC] Scoped no-alias metadata
----- 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
2012 Dec 03
0
[LLVMdev] [RFC] Scoped no-alias metadata
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