similar to: Alias scope and noalias metadata

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

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

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

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:

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 Johannes, Silly as me. I just figured out how to correctly use 'alias' metadata. I should define them in IR like below: !3 = !{!3} !4 = !{!4} !5 = !{!5, !3} !6 = !{!6, !4} And then use !5 and !6. The below usage is wrong: !3 = !{!3} !4 = !{!4} Then use !3 and !4 in IR. BR, Terry On Fri, Jul 24, 2020 at 12:12 AM Johannes Doerfert < johannesdoerfert at gmail.com> wrote:

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:

Hi Johannes, Thanks for your help. I tried with something like below and nothing changes. Maybe I am doing something wrong? 246001 check_exce_succ59: ; preds = %check_exce_succ40 **246002 %mem_base60 = load i8*, i8** %mem_base_addr_ptr, align 8, !alias.scope !3 246003 %offset161 = add i32 %call56, 4 246004 %12 = sext i32 %offset161 to i64 246005 %maddr62 =

Hi, I have a test-case for which I seem to be getting incorrect information from basic-aa alias-analysis. Here it is: #include <stdio.h> #define ARR_SIZE 4 char c[ARR_SIZE]; char *pc[ARR_SIZE]; char **ppc = pc; int main() { pc[0] = &c[0]; pc[1] = &c[1]; pc[2] = &c[2]; pc[3] = &c[3]; printf(" ppc: %p\n" " pc : %p\n" " c :

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

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

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

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 use the restrict qualifier on function arguments in Clang where we translate the restrict qualifier as a

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

> On Nov 6, 2020, at 17:32, Johannes Doerfert <johannesdoerfert at gmail.com> wrote: > > Cool! I really like the idea. I left a comment about metadata preservation below. > Once this is available we will certainly employ it to understand OpenMP programs better. That sounds like a great use case! Having multiple different uses cases during the bring-up would be very helpful to

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

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