search for: hgreving

...an _existing_ chain. e.g. adding A->B to the DAG is ok. But adding A->B and next C->D with B->C is the problem. I appreciate the input On Thu, Jul 16, 2020 at 2:04 PM Matt Arsenault <arsenm2 at gmail.com> wrote: > > > > On Jul 16, 2020, at 17:00, Hendrik Greving <hgreving at google.com> wrote: > > > > > No, non-sideeffecting operations can be legalized as compiler-rt calls > > > > Right, but not as "regular" nodes with side-effects? I guess you could > search and analyze the DAG manually but that seems hacky. Maybe somethin...

...ith side-effects? I guess you could search and analyze the DAG manually but that seems hacky. Maybe something that one day LLVM could support natively. On Thu, Jul 16, 2020 at 11:55 AM Matt Arsenault <arsenm2 at gmail.com> wrote: > > > On Jul 16, 2020, at 14:47, Hendrik Greving <hgreving at google.com> wrote: > > I think their originating node already has a chain (i.e. mem operand or > side effect in llvm-ir) > > > > No, non-sideeffecting operations can be legalized as compiler-rt calls > > -Matt > -------------- next part -------------- An HTML att...

...g more robust that also works with clang. On Mon, May 18, 2020 at 8:44 PM Michael Kruse <llvmdev at meinersbur.de> wrote: > What would be its semantics? When would clang attach that attribute? > > Michael > > Am Mo., 18. Mai 2020 um 14:01 Uhr schrieb Hendrik Greving < > hgreving at google.com>: > > > > Would you guys be open to supporting a new hint with the right > semantics, like e.g. llvm.loop.noalias_accesses?! I would need to find > support in clang however and the main point of support would be the loop > unroller behaving as stated in the OP....

...#pragma omp ivdep, a compiler is not required to vectorize > the loop. > > In LLVM, runtime/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 usin...

> Chain doesn't guarantee that operations on parallel chains don't get interleaved This would be a sequential chain... > This is the case for all operations expanded as library calls I think their originating node already has a chain (i.e. mem operand or side effect in llvm-ir). My case is a arithmetic node without ordering constraints (divrem) getting lowered into sth that _does_

...dding A->B to the DAG is ok. But > adding A->B and next C->D with B->C is the problem. I appreciate the input > > > > On Thu, Jul 16, 2020 at 2:04 PM Matt Arsenault <arsenm2 at gmail.com> wrote: > > > > > On Jul 16, 2020, at 17:00, Hendrik Greving <hgreving at google.com> wrote: > > > > > No, non-sideeffecting operations can be legalized as compiler-rt calls > > > > Right, but not as "regular" nodes with side-effects? I guess you could > search and analyze the DAG manually but that seems hacky. Maybe somethin...

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 dependencies, usually means effectively

...B->C is the problem. I appreciate the input >>> >>> >>> >>> On Thu, Jul 16, 2020 at 2:04 PM Matt Arsenault <arsenm2 at gmail.com> >>> wrote: >>> >>> >>> >>> > On Jul 16, 2020, at 17:00, Hendrik Greving <hgreving at google.com> >>> wrote: >>> > >>> > > No, non-sideeffecting operations can be legalized as compiler-rt >>> calls >>> > >>> > Right, but not as "regular" nodes with side-effects? I guess you could >>> search...