similar to: restrict func param losing noalias when inlined

Johannes, Thanks, I have been following along some of the thread(s) and the phab reviews. The scope of this work is more encompassing than our current needs and I've looked at trying to carve a piece out. It's not clear to me what purpose the llvm.noalias intrinsic serves right now. Also, if a mem instruction has !noalias metadata, then it should not be aliased, but I must be missing

I wanted to confirm that my understanding of the situation is correct. For background, I've been working have an optimizer pass for a research architecture which works best when there are large basic blocks and good alias analysis results. I first noticed the issue in rgbcmy01 from eembc-1.1, but have created a simpler test case which demonstrates the same issue which is unencumbered by the

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

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

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

----- 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

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 >

Hi everyone, As many of you might know, LLVM now has scoped noalias metadata (http://llvm.org/docs/LangRef.html#noalias-and-alias-scope-metadata) -- it allows us to preserve noalias function argument attributes when inlining, in addition to allowing frontends to add otherwise non-deducible aliasing properties to memory accesses. This currently works well, but needs a change and an intrinsic, as

Hal, Johannes, Thanks for the feedback. I have been digging into this a little bit more and was able to have some of this metadata being generated. Nevertheless, I am confused about the semantics of this metadata. Let me explain: I was expecting the alias metadata to complement the information that alias analysis passes compute. However, it seems that the alias information of the pointers used

Hi all, I'm trying to understand the semantics of noalias arguments, and I'm not entirely sure I got it correctly. To the best of my understanding, if an argument is declared noalias, "This indicates that pointer values based on the argument do not alias pointer values which are not based on it" implies, among other things, that it cannot alias any other argument, even if that

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

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

On Fri, Sep 21, 2012 at 3:08 PM, Welson Sun <welson.sun at gmail.com> wrote: > OK, with the restrict type qualifier, it is a little bit better: > > The IR's function signature becomes: > define void @foo(i32* noalias %a, i32* noalias %b, i32* noalias %c) nounwind > { > > Now the AA result: > Function: foo: 13 pointers, 0 call sites > NoAlias: i32* %a,

Here is the result of running mem2reg then basicaa, it is even worse: (%a should be alias to %0, and partial alias to %3) opt -mem2reg -basicaa -aa-eval -print-all-alias-modref-info < foo.s > /dev/null Function: foo: 6 pointers, 0 call sites NoAlias: i32* %a, i32* %b NoAlias: i32* %a, i32* %c NoAlias: i32* %b, i32* %c PartialAlias: i32* %1, i32* %a NoAlias:

OK, with the restrict type qualifier, it is a little bit better: The IR's function signature becomes: define void @foo(i32* noalias %a, i32* noalias %b, i32* noalias %c) nounwind { Now the AA result: Function: foo: 13 pointers, 0 call sites NoAlias: i32* %a, i32* %b NoAlias: i32* %a, i32* %c NoAlias: i32* %b, i32* %c NoAlias: i32* %a, i32** %a_addr NoAlias:

Hi all, In LLVM language reference I read that one can use noalias and alias.scope metadata to provide more detailed information about pointer aliasing. However, I was unable to obtain any LLVM IR annotations using this metadata from any LLVM optimization pass or Clang frontend (am I missing something?). If I understand it correctly, this information would complement the type-based alias

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,

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, Looking at how noalias is defined: https://llvm.org/docs/LangRef.html#noalias-and-alias-scope-metadata "When evaluating an aliasing query, **if for some domain**, the set of scopes with that domain in one instruction’s alias.scope list is a subset of (or equal to) the set of scopes for that domain in another instruction’s noalias list, then the two memory accesses are assumed not to

Hi all, ## Status: During the past weeks I have updated the restrict patches with various improvements: - the ScopedNoAliasAA now also works together with the new pass manager - the SLPVectorizer now works nice with the noalias support. - there were some issues with some of the options enabling/disabling full restrict. These have been fixed. - various smaller enhancements. Today, I rebased the