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

2019-10-18 Thread Hideki Saito via Phabricator via cfe-commits
hsaito added a comment. In D69088#1715210 , @Meinersbur wrote: > I'd rather just enable them with a command-line switch, such as > `-fexperimental-transform`. This direction works for me. `-fexperimental-transform-pragma` might be better, though.

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

2019-10-18 Thread Hideki Saito via Phabricator via cfe-commits
hsaito added a comment. In D69088#1714575 , @Meinersbur wrote: > In D69088#1714020 , @hsaito wrote: > > > Personally, I like the intent. I don't foresee a clear (enough) path to get > > there. This leads to

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

2019-10-17 Thread Hideki Saito via Phabricator via cfe-commits
hsaito added a comment. In D69088#1714019 , @Meinersbur wrote: > In D69088#1713933 , @hsaito wrote: > > > Have we established general consensus for the desire to have the flexible > > enough loop optimization pass

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

2019-10-17 Thread Hideki Saito via Phabricator via cfe-commits
hsaito added a comment. Have we established general consensus for the desire to have the flexible enough loop optimization pass ordering to accomplish the outcome of the new directive, and shared vision for the path to get there? If we are making this a general clang directive, I'd like to see

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

2019-10-17 Thread Hideki Saito via Phabricator via cfe-commits
hsaito added a comment. @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. Repository: rC Clang CHANGES SINCE LAST ACTION

[PATCH] D66199: [docs] loop pragmas

2019-10-10 Thread Hideki Saito via Phabricator via cfe-commits
hsaito accepted this revision. hsaito added a comment. This revision is now accepted and ready to land. LGTM. Please wait for a few days in case others have more comments. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D66199/new/ https://reviews.llvm.org/D66199

[PATCH] D66199: [docs] loop pragmas

2019-10-10 Thread Hideki Saito via Phabricator via cfe-commits
hsaito added inline comments. Comment at: docs/LanguageExtensions.rst:3069 +There are loop hints that control transformations (e.g. vectorization, loop +unrolling) and there loop hints that set transformation options (e.g. +``vectorize_width``, ``unroll_count``). Pragmas

[PATCH] D66796: [clang] Loop pragma vectorize(disable)

2019-09-09 Thread Hideki Saito via Phabricator via cfe-commits
hsaito added a comment. In D66796#1663868 , @SjoerdMeijer wrote: > That's exactly the reason why I think `vectorize(disable)` should disable > vectorisation for that loop. I just don't see what else a user would expect. I agree with you. Now on the

[PATCH] D66796: [clang] Loop pragma vectorize(disable)

2019-09-09 Thread Hideki Saito via Phabricator via cfe-commits
hsaito added a comment. There are two ways to think. 1. vectorize(disable) as in disable the LoopVectorize pass itself. 2. vectorize(disable) as in disabling the loop vectorization transformation It all depends on to whom we are providing these pragmas. If we are providing pragmas for

[PATCH] D57978: [CodeGen] Generate follow-up metadata for loops with more than one transformation.

2019-03-19 Thread Hideki Saito via Phabricator via cfe-commits
hsaito added a comment. In D57978#1435473 , @Meinersbur wrote: > ping This is a good follow up for rL348944 , but I have no familiarity to the code under Clang. So, let me thank you for doing this work and move