similar to: alias.scope and local restricted C pointers

On 08/16/2018 07:52 PM, Bekket McClane via llvm-dev wrote: > > >> On Aug 16, 2018, at 4:41 PM, Troy Johnson via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Concerning slide 16 >> of https://llvm.org/devmtg/2017-02-04/Restrict-Qualified-Pointers-in-LLVM.pdf >>   >> Specifically “Currently, LLVM

Hi all, I have seen in multiple cases that, usually at the beginning of the function. if a BranchInst is encountered the next block might have %0 indicated as predecessor. I think it is a way to say "no predecessors found". Am I correct? Few examples just for clarifying what I mean: define noalias %struct.png_struct_def* @png_create_read_struct_2(i8* %user_png_ver, i8* %error_ptr, void

On 06/28/2018 10:59 AM, Hal Finkel wrote: > Hi, Jeroen, > > We should move these conversations to llvm-dev so that they don't get > missed and others can contribute. Can I cc the list? [+llvm-dev] - Jeroen consented. > > Doing this will mean that the logic for when to remove dead llvm.noalias > intrinsics will become more complicated. That might be worthwhile. So >

Hi there! Greetings! I am wondering how I may be able get these annotations !noalias and !alias.scope to show up- I have a function with restrict added to the arguments but I do not see these intrinsics with clang -emit-llvm. Which pass inserts them? Best, Ram -------------- next part -------------- An HTML attachment was scrubbed... URL:

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

On 01/28/2013 12:58 PM, Pekka Jääskeläinen wrote: > Hi, > > Attached is a patch which uses a simple "parallel_loop" metadata attached > to the loop branch instruction in the loop latch for skipping > cross-iteration > memory dependency checking in the LoopVectorizer. This was briefly > discussed > in the email thread "LoopVectorizer in OpenCL C work group

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

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

Hi, I am trying to figure out the best way to add some extra metadata to the store and load llvm-ir instructions: The metadata content is a 'Value*' expression representing a side channel, containing dependency information that is used to help the Scoped Alias Analysis. Optimizations that don't know about this side channel can safely drop it, where the only effect would be on the

On Wed, Dec 12, 2012 at 01:59:55PM -0800, Dan Gohman wrote: > On Wed, Dec 12, 2012 at 1:26 PM, Joerg Sonnenberger > > The original issue is that clang maps restrict on function arguments to > > NoAlias and that makes compares against the address of global variables > > false. Minimal test case: > > > > @y = external global i32 > > > > define zeroext i1

On Tue, Dec 11, 2012 at 03:17:43AM -0800, Chandler Carruth wrote: > As Joerg pointed out in IRC, 'y' is an lvalue, but we do not use it to > access the object it designates, we only use it to compute the address, and > thus restrict should have no bearing on it. That would in turn make Clang's > optimization incorrect and also seems likely to make 'noalias'

On Wed, Dec 12, 2012 at 2:45 PM, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: > On Wed, Dec 12, 2012 at 01:59:55PM -0800, Dan Gohman wrote: >> On Wed, Dec 12, 2012 at 1:26 PM, Joerg Sonnenberger >> > The original issue is that clang maps restrict on function arguments to >> > NoAlias and that makes compares against the address of global variables >>

On Wed, Dec 12, 2012 at 8:38 AM, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: > On Tue, Dec 11, 2012 at 03:17:43AM -0800, Chandler Carruth wrote: >> As Joerg pointed out in IRC, 'y' is an lvalue, but we do not use it to >> access the object it designates, we only use it to compute the address, and >> thus restrict should have no bearing on it. That

Hello, On Nov 4, 2009, at 1:51 AM, Hans Wennborg wrote: > > > / Hans > Index: lib/Analysis/BasicAliasAnalysis.cpp > =================================================================== > --- lib/Analysis/BasicAliasAnalysis.cpp (revision 86023) > +++ lib/Analysis/BasicAliasAnalysis.cpp (working copy) > @@ -633,6 +633,15 @@ > AliasAnalysis::AliasResult >

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, Attached is a patch which uses a simple "parallel_loop" metadata attached to the loop branch instruction in the loop latch for skipping cross-iteration memory dependency checking in the LoopVectorizer. This was briefly discussed in the email thread "LoopVectorizer in OpenCL C work group autovectorization". It also converts the "min iteration count to vectorize"

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

On Wed, Dec 12, 2012 at 11:01:01AM -0800, Dan Gohman wrote: > > Is that > > assumption violated if I explicitly cast away const and pass the result > > to a function with NoAlias argument? > > Not immediately, no. It means that you can't access the constant > pointer's pointee directly within the noalias argument's scope. Access > to that object must go

This is the first patch I've sent to this project. Please be gentle :) LLVM fails to remove the dead load in the following code when running $./llvm-as -o - test.ll | ./opt -O3 -o - | ./llvm-dis -o - %t = type { i32 } declare void @foo(i8*) define void @f(%t* noalias nocapture %stuff ) { %p = getelementptr inbounds %t* %stuff, i32 0, i32 0 %before = load i32* %p call void

On Wed, Dec 12, 2012 at 1:26 PM, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: > On Wed, Dec 12, 2012 at 11:01:01AM -0800, Dan Gohman wrote: >> > Is that >> > assumption violated if I explicitly cast away const and pass the result >> > to a function with NoAlias argument? >> >> Not immediately, no. It means that you can't access the