Meinersbur added a comment. In D69088#1713831 <https://reviews.llvm.org/D69088#1713831>, @tyler.nowicki wrote:
> In D69088#1713648 <https://reviews.llvm.org/D69088#1713648>, @Meinersbur > wrote: > > > In D69088#1713623 <https://reviews.llvm.org/D69088#1713623>, @hsaito wrote: > > > > > @Meinersbur, if I remember correctly, there was an RFC discussion on this > > > topic, right? If yes, would you post the pointer to that? I need a > > > refresher on what has been discussed/settled in the past. > > > > > > https://lists.llvm.org/pipermail/cfe-dev/2018-May/058141.html > > > Sorry if this is answered in the patches but what happens if a loop has both > #pragma clang loop and transform defined before it? I guess it probably > shouldn't work. Yes, the plan was to make it an hard error. I unfortunately forgot to add that to D69091 <https://reviews.llvm.org/D69091>, thanks for reminding me. In the current implementation the #pragma clang loop would be applied first, but it's not intentional. > Perhaps instead you could create a new option to indicate that the order > should be respected. > > #pragma clang loop respect_order <- optionally with (true) or (false) > > That approach would avoid the inevitable conflicts of having both loop and > transform pragmas on the same loop. There is also a syntax difference: #pragma clang loop vectorize_width(4) compared to #pragma clang transform vectorize width(4) which in a similar form is also how it is done in OpenMP: #pragma omp simd simdlen(4) IMHO, a `respect_order` option is problematic, not only because it influences parsing while being parsed. It also makes the preferable behavior clunkier to use. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D69088/new/ https://reviews.llvm.org/D69088 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
