similar to: [LLVMdev] Upcoming Changes/Additions to Scoped-NoAlias metadata

----- Original Message ----- > From: "Chandler Carruth" <chandlerc at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Thursday, November 13, 2014 7:02:58 PM > Subject: Re: [LLVMdev] Upcoming Changes/Additions to Scoped-NoAlias metadata > > > >

----- Original Message ----- > From: "Raul Silvera" <rsilvera at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Chandler Carruth" <chandlerc at google.com>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Friday, November 14, 2014 10:34:39 AM > Subject: Re: [LLVMdev] Upcoming

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

Hello everyone, In December, I had started a thread on scoped no-alias metadata in order to represent C99 'restrict' pointer information at the IR level: http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-December/056586.html At this point, we also have another important use case: preserving the existing 'noalias' attributes on pointers after inlining. My original proposal was

Hello again, When I had originally discussed this proposal, it was thought that we would not have to worry about control dependencies on the noalias metadata because such dependencies could only present a problem when loads or stores are merged (RAUW is called), and transformations should drop metadata when that happens. Now I'm worried that this is not true. Here's a simple example:

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:

----- Original Message ----- > From: "Raul Silvera" <rsilvera at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Chandler Carruth" <chandlerc at google.com>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Tuesday, November 18, 2014 9:09:40 PM > Subject: Re: [LLVMdev] Upcoming

On 11/13/2014 05:02 PM, Chandler Carruth wrote: > > This intrinsic needs to carry control dependencies (it cannot be > hoisted out of a loop, for example) -- in this sense it is very > much like @llvm.assume. And like @llvm.assume, we'll need to add > logic to various passes to ignore it as appropriate so that it > does not block optimizations

----- Original Message ----- > From: "Raul Silvera" <rsilvera at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Chandler Carruth" <chandlerc at google.com>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Monday, November 24, 2014 7:20:04 PM > Subject: Re: [LLVMdev] Upcoming Changes/Additions

----- Original Message ----- > From: "Raul Silvera" <rsilvera at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Chandler Carruth" <chandlerc at google.com>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Friday, November 14, 2014 12:15:51 PM > Subject: Re: [LLVMdev] Upcoming

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

----- Original Message ----- > From: "Raul Silvera" <rsilvera at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Chandler Carruth" <chandlerc at google.com>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Tuesday, November 18, 2014 11:23:25 AM > Subject: Re: [LLVMdev] Upcoming

Hello, Currently the noalias attribute can be applied on function parameters and return value, or via scoped alias on store. The problem is that there is no easy way to apply the noalias attribute on a pointer that is loaded indirectly (e.g from the field of an aggregate, or from a memory location - though for this you can still use scoped alias, but they are a lot more intrusive) The idea

----- Original Message ----- > From: "Raul Silvera" <rsilvera at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Chandler Carruth" <chandlerc at google.com>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Friday, November 14, 2014 5:31:24 PM > Subject: Re: [LLVMdev] Upcoming Changes/Additions

----- Original Message ----- > From: "Raul Silvera" <rsilvera at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Chandler Carruth" <chandlerc at google.com>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Monday, November 17, 2014 11:26:57 AM > Subject: Re: [LLVMdev] Upcoming

Great, thanks! Are you planning on just talking about these things with slides? Do we have other things to which we can link for people to read? -Hal Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory ________________________________ From: Tarique Islam <tislam at ca.ibm.com> Sent: Thursday, May 21, 2020 8:19:31 AM To:

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

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

Concerning slide 16 of https://llvm.org/devmtg/2017-02-04/Restrict-Qualified-Pointers-in-LLVM.pdf Specifically "Currently, LLVM only supports restrict on function arguments, although we have a way to preserve that information if the function is inlined." Is that statement still accurate? It would seem that https://llvm.org/docs/LangRef.html#noalias-and-alias-scope-metadata should be

Hi all, I think I've managed to trick the legacy MemCpyOpt (MCO) into an incorrect transform, but I would like to confirm the validity of my counterexample before working on the fix. Suppose the following IR: %T = type { i32, i32 } define void @f(%T* %a, %T* %b, %T* %c, %T* %d) { %val = load %T, %T* %a, !alias.scope !{!10} ; store1 ; Aliases the load