similar to: [LLVMdev] Mixing noalias and regular arguments

Displaying 20 results from an estimated 5000 matches similar to: "[LLVMdev] Mixing noalias and regular arguments"

2013 May 26
0
[LLVMdev] Mixing noalias and regular arguments
Ping? (Is there a code owner for AA, btw?) From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Kuperstein, Michael M Sent: Tuesday, May 21, 2013 18:23 To: LLVMdev at cs.uiuc.edu Cc: Raoux, Thomas F Subject: [LLVMdev] Mixing noalias and regular arguments Hi all, I'm trying to understand the semantics of noalias arguments, and I'm not entirely sure I
2013 May 26
2
[LLVMdev] Mixing noalias and regular arguments
Kuperstein, Michael M wrote: > Ping? Pong! Sorry for the slow review, I had this patch starred but hadn't got around to it. Yes, the rationale and implementation are correct. > (Is there a code owner for AA, btw?) (It falls back on the more general code owner who is Chris Lattner in this case, "Everything not covered by someone else".) +/// isNoAliasArgument - Return true
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
2013 May 27
0
[LLVMdev] Mixing noalias and regular arguments
Thanks Nick! Can you just check sanity before I commit? (Or suggest a better name for the function...) -----Original Message----- From: Nick Lewycky [mailto:nicholas at mxc.ca] Sent: Sunday, May 26, 2013 09:54 To: Kuperstein, Michael M Cc: LLVMdev at cs.uiuc.edu Subject: Re: [LLVMdev] Mixing noalias and regular arguments Kuperstein, Michael M wrote: > Ping? Pong! Sorry for the slow review,
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
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
2017 Dec 26
3
Why is remalloc not marked as noalias?
Hello, According to my understanding, it seems that the result of realloc will not technically alias the original pointer. When the realloc is done in-place the reference <http://en.cppreference.com/w/c/memory/realloc> says: "The original pointer ptr is invalidated and any access to it is undefined behavior (even if reallocation was in-place)." Additionally from the C11 standard
2010 Jun 09
1
[LLVMdev] AliasAnalysis Documentation Ambiguity
Hi, The description of the alias method in AliasAnalysis reads: alias - The main low level interface to the alias analysis implementation. Returns a Result indicating whether the two pointers are aliased to each other. This is the interface that must be implemented by specific alias analysis implementations. This implies that alias can run on ANY two Values without restrictions. However, line
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 Jul 16
2
[LLVMdev] LICM for function calls
The common case is wanting LICM to hoist a loop-invariant function call into the pre-header of a loop where the trip count is unknown - and, in particular, not known to be > 0. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Hal Finkel Sent: Thursday, July 16, 2015 08:38 To: Raoux, Thomas F Cc: llvmdev at cs.uiuc.edu Subject:
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
2010 Nov 14
0
[LLVMdev] noalias locals
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
2020 Sep 29
2
restrict func param losing noalias when inlined
Given some code: void func (float * restrict a, float *b) { for (int i =0; i < 100; ++i) { a[i] = b[i] + 1; } } float * aa; float * bb; int main() { func(aa, bb); return 0; } produces IR that has the llvm.noalias intrinsic along with the !noalias metadata:for both the load and store, however, AA returns MayAlias, I would expect a NoAlias? This is also an older version of llvm:
2010 Nov 14
2
[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
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,
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
2015 Nov 09
2
noalias parameter attribute not currently exploited by alias analysis?
----- Original Message ----- > From: "Alex Bradbury" <asb at asbradbury.org> > To: llvm-dev at lists.llvm.org > Cc: "Hal Finkel" <hfinkel at anl.gov> > Sent: Sunday, November 8, 2015 10:30:09 AM > Subject: Re: noalias parameter attribute not currently exploited by alias analysis? > > On 2 November 2015 at 20:20, Alex Bradbury <asb at
2010 Nov 14
2
[LLVMdev] noalias locals
Right now, I don't see any way to declare that a pointer value within a function does not alias any pointer not based on it. Basically, I would like to be able to apply "noalias" to an instruction/virtual reg the same way that noalias is applied to function arguments. A few weeks ago when discussing devirtualization possibilities in C++, it turned out that while you can assume that
2010 Nov 14
0
[LLVMdev] noalias locals
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 >