[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 ___

[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

[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

[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

<    1   2   3   4   5