[PATCH] D69088: [Lex] #pragma clang transform

[Michael Kruse via Phabricator via cfe-commits]

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