search for: no_alia

...iteration should cover this use case also if the metadata also includes the iteration id. Then at the unroll time, the metadata can be replicated and the id incremented. An alias analyzer (something similar we have in pocl for unrolled/chained work items) then can check for this metadata and return NO_ALIAS for accesses from different iterations. Going even further, maybe this same (or similar) format can be used to retain restricted pointer (noalias) information across inlining. Lack of this has been a bit of a nuisance for us in TCE. In the restricted ptr case one wants to mark pointers with some...

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

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"

...> 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?  > > Yes, correct (actually I was just working on restrict, no_alias and > alias.scope attributes). The inliner also propagates them correctly.  > >> It would seem >> that https://llvm.org/docs/LangRef.html#noalias-and-alias-scope-metadata should >> be sufficiently general to honor C’s restrict qualifier on local >> pointers, >>...

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

...struction originates from) and a sequence ID. So, lots of metadata bloat. These annotations allow finding the matching instructions later on to vectorize multiple work items together by just combining the matching instructions from the different WIs. The alias analyzer uses this metadata to return NO_ALIAS for any memory access combination where the accesses are from different work items within the same parallel region (the specs say if they do alias, the results are undefined, thus a programmer's fault). With your annotations this hack could be probably cleaned up by using the "parallel f...

On Mon, 13 Aug 2012 12:38:02 +0300 Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi> wrote: > Hi, > > On 08/10/2012 11:06 PM, Hal Finkel wrote: > > I'd like to see support in clang/LLVM for multi-core parallelism, > > especially support for OpenMP. I think that the best way to do > > this is by designing an LLVM-based API (metadata and intrinsics) >

...) and a sequence ID. So, lots of metadata bloat. > > These annotations allow finding the matching instructions later on to > vectorize multiple work items together by just combining the matching > instructions from the different WIs. The alias analyzer uses this > metadata to return NO_ALIAS for any memory access combination where > the accesses are from different work items within the same parallel > region (the specs say if they do alias, the results are undefined, > thus a programmer's fault). > > With your annotations this hack could be probably cleaned up by u...