[PATCH] D47267: [UnrollAndJam] Add unroll_and_jam pragma handling
Meinersbur added a comment. The RFC: https://lists.llvm.org/pipermail/cfe-dev/2018-May/058141.html https://reviews.llvm.org/D47267 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D47267: [UnrollAndJam] Add unroll_and_jam pragma handling
Meinersbur added a comment. Yes, this is what I had in mind. Thank you. I am preparing an RFC on what I am trying to do. This should clarify our goals and to what extend `#pragma clang loop` conflicts with it. https://reviews.llvm.org/D47267 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D47267: [UnrollAndJam] Add unroll_and_jam pragma handling
Meinersbur added a comment. In https://reviews.llvm.org/D47267#1109912, @dmgreen wrote: > > Could we maybe disable the #pragma clang loop unroll_and_jam spelling ftm > > to avoid compatibility issues? > > Sure, I'm not against. It sounds like you have opinions on how this should > work. That's good. If there are multiple clang loop pragma's, what is the > expected behaviour there? > > In the llvm side of this, in the unroll and jam pass, I made it so that a > loop with "llvm.loop.unroll" metadata without any "llvm.loop.unroll_and_jam" > metadata will not do unroll and jam, it will leave the loop for the unroller. > On the expectation that the use really wants to unroll (and it applies to > llvm.loop.unroll.disable too, disabling unroll and jam as well as unroll). I > haven't done anything with other loop metadata though. I'd expect that transformations "stack up". E.g. #pragma unroll_and_jam #pragma unroll(4) which I'd expect to unroll by a factor of 4 first, then try to unroll-and-jam (which I am not sure https://reviews.llvm.org/D41953 can do due to then containing 4 loops). On the other hand #pragma unroll(4) #pragma unroll_and_jam should unroll-and-jam, and then unroll the outer loop by a factor of 4. https://reviews.llvm.org/D47267 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D47267: [UnrollAndJam] Add unroll_and_jam pragma handling
Meinersbur added a comment. This is straightforward in that it clones the implementation of `#pragma unroll` for `unroll_and_jam`. Hence, it also shares the same problem of clang's LoopHints, namely that the order of loop transformations (if there are multiple on the same loop: loop distribution, vectorization, etc) is defined by the order of the passes in the pass pipeline, which should be an implementation detail. I am currently working on this topic. Could we maybe disable the `#pragma clang loop unroll_and_jam` spelling ftm to avoid compatibility issues? However, the problem already exists for the other loop hints, so I will have to ensure compatibility with those anyway. https://reviews.llvm.org/D47267 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D33774: [CodeGen] Make __attribute__(const) calls speculatable
Meinersbur added a comment. Definition of `__attibute__((const))` from https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes > Many functions do not examine any values except their arguments, and have no > effects except the return value. Basically this is just slightly more strict > class than the pure attribute below, since function is not allowed to read > global memory. > Note that a function that has pointer arguments and examines the data > pointed to must not be declared const. Likewise, a function that calls a > non-const function usually must not be const. It does not make sense for a > const function to return void. Definition of `speculatable` from http://llvm.org/docs/LangRef.html#function-attributes > This function attribute indicates that the function does not have any effects > besides calculating its result and does not have undefined behavior. https://reviews.llvm.org/D33774 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
