search for: parallel_accesses

This is interesting! So are you saying that loop.parallel_accesses strictly loop parallel, and says nothing about aliasing? I see, I guess we may have been "abusing" the hint and re-purposed it. But isn't llvm's vectorizer using loop.parallel_accesses to vectorize loops including vectorize memory accesses that if you ignore loop-carried dependenc...

Hi, in our backend, which is unfortunately not upstreamed, we are relying on llvm.loop.parallel_accesses metadata for certain passes like software pipelining so we can re-order instructions. Ideally, we would want the loop unroller to support the notion of the loop's parallelism in its pre-unrolled version. This probably should happen by propagating !alias.scope and !alias metadata. Is there any p...

Am Mi., 24. Juni 2020 um 10:12 Uhr schrieb David Blaikie <dblaikie at gmail.com>: > > As mentioned in the Differential, generating the tests automatically > > will lose information about what actually is intended to be tested, > > Agreed - and I didn't mean to suggest tests should be automatically > generated. I work pretty hard in code reviews to encourage tests to

...time/partial unrolling only takes place after > vectorization, so there is less of an issue there. > > Michael > > > Am Do., 14. Mai 2020 um 16:16 Uhr schrieb Hendrik Greving < > hgreving at google.com>: > > > > This is interesting! So are you saying that loop.parallel_accesses > strictly loop parallel, and says nothing about aliasing? I see, I guess we > may have been "abusing" the hint and re-purposed it. But isn't llvm's > vectorizer using loop.parallel_accesses to vectorize loops including > vectorize memory accesses that if you ignore lo...

...the unroller merges iterations, loop parallel no longer depicts the original iterations. So the obvious idea was using noalias scope metadata for this, and llvm.loop.noalias_acccesses would cause the unroller to propagate different scopes for each iteration. Thinkable is also to keep the llvm.loop.parallel_accesses, and the unroller propagates a new type of metadata analog to noalias scope, but loop_parallel scope or something like that. We have methods to achieve this with intrinsics, but I am looking for something more robust that also works with clang. On Mon, May 18, 2020 at 8:44 PM Michael Kruse <llv...

...is marked parallel for both > loops. > > Even the change should have no effect on correctness, `ninja > check-llvm` fails: > >     test/Transforms/Inline/parallel-loop-md-merge.ll > >      string not found in input >     ; CHECK: ![[ACCESSES_INNER]] = !{!"llvm.loop.parallel_accesses", > ![[ACCESS_GROUP_INNER]]} >              ^ >     <stdin>:45:1: note: scanning from here >     !7 = !{!"llvm.loop.parallel_accesses", !5} >     ^ >     <stdin>:45:1: note: with "ACCESSES_INNER" equal to "7" >     !7 = !{!"l...

...(((a[p + i * lda]).imag)) * (((x[p]).imag)); (((r[i]).imag)) += (((a[p + i * lda]).imag)) * (((x[p]).real)) - (((a[p + i * lda]).real)) * (((x[p]).imag)); }; } The specification on this loop is incorrect as the parallel_accesses metadata indicate that there is no loop carried memory dependence, which is not true in this case. In the default flow, LICM hoists and sinks the loads and stores of r[i] and the loop vectorizer vectorizes this loop based on “llvm.loop.parallel_accesses” metadata. If the hoist and sink transforma...

...to. Because of (b), transformation passes can change a loop's llvm.loop metadata such that llvm.mem.parallel_loop_access may point to an orphaned LoopID. Patch [3] fixes this issue. Instead of instructions referencing the loops they are parallel to, it adds a new loop attribute "llvm.loop.parallel_accesses" that references the instructions. Any loop transformation that changes the loop metadata will by default carry-over the llvm.loop.parallel_accesses property and the information retained. Since global metadata cannot reference instructions, [3] also introduces a new distinct metadata type tha...

...r `AccGroups2` comes first, the instruction is marked parallel for both loops. Even the change should have no effect on correctness, `ninja check-llvm` fails: test/Transforms/Inline/parallel-loop-md-merge.ll string not found in input ; CHECK: ![[ACCESSES_INNER]] = !{!"llvm.loop.parallel_accesses", ![[ACCESS_GROUP_INNER]]} ^ <stdin>:45:1: note: scanning from here !7 = !{!"llvm.loop.parallel_accesses", !5} ^ <stdin>:45:1: note: with "ACCESSES_INNER" equal to "7" !7 = !{!"llvm.loop.parallel_accesses", !5...

On 03/02/2013 08:44 PM, Tobias Grosser wrote: > If the use of ivdep is correct, it seems necessary to _not_ annotate the loads > and stores from and to 't'. Only after 't' is moved into a register, the loop is > actually parallel on the IR level. I didn't realize this is a problem in general because in pocl we explicitly "privatize" the OpenCL C kernel

On 03/01/2013 10:05 PM, Redmond, Paul wrote: [...] > I have discovered that you can provide a custom inserter to IRBuilder (who knew!). This has basically solved all my problems and allowed me to generate the proper metadata with minimal changes to clang codegen. Currently it adds the metadata to all loads and stores but I don't think this is a problem and can be refined later if necessary.