similar to: [LLVMdev] [RFC] Scoped no-alias 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>, "Clang Developers" <cfe-dev at cs.uiuc.edu>, "Dan Gohman" > <dan433584 at gmail.com> > Sent: Sunday, December 2, 2012

----- 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: Sunday, December 2, 2012

On Sun, Dec 2, 2012 at 8:05 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- 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>, "Clang Developers" <cfe-dev at cs.uiuc.edu>,

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

On Mon, Dec 3, 2012 at 11:43 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

On Sun, Dec 2, 2012 at 12:48 PM, Hal Finkel <hfinkel at anl.gov> wrote: > Hello, > > I'd like to propose a new form of memory-aliasing metadata: scoped > no-alias metadata. This can be used to model local 'restrict' pointers in > C99, but should also be useful for other frontends (I think, for example, > that Fortran will want this as well). Currently, we only

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

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

----- 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 12/2/2012 2:48 PM, Hal Finkel wrote: > > [...] As a result, we'll need to assign a unique identifier to each lifetime region (roughly a block in C99, although this may be only a partial block if a restrict pointer is declared in the middle of the block). Whether restricted pointer is declared in the middle of a block or not, does not matter from the standard's perspective.

----- 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: Monday, November 17, 2014 11:26:57 AM > Subject: Re: [LLVMdev] Upcoming

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

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

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:

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

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

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

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