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

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


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

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

[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 hesitation of adding a new non-experimental pragma and 
> > present it to programmers. If you call it experimental, it's easier for me 
> > to swallow.
>
>
> Is there anything more to do than mentioning as being it experimental in the 
> (no-patch-available-yet) docs?


If there is a precedence, just follow that. Else, how to spell an experimental 
clang pragma would be a good discussion topic by itself. If I need to provide a 
discussion starter, I'd say how about transform_experimental instead of 
transform. All I ask is somehow make it easier for programmers to know it is 
experimental so that they won't use it w/o first reading about the current 
state of support. I don't have a strong opinion about how to do so.

If others with stakes in loop optimizations foresee a clear enough path to get 
there, I won't insist this being experimental, but I would like to understand 
the path.

Thanks,
Hideki


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

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

[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 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 the vision to get there w/o 
> > depending on polly. If this is already discussed and settled, pointer to 
> > that is appreciated so that I can learn.
>
>
> Response to the RFCs was meager. However, I got positive feedback at various 
> conferences, including last year's DevMtg where my version for loop 
> transformations was a technical talk .


Personally, I like the intent. I don't foresee a clear (enough) path to get 
there. This leads to hesitation of adding a new non-experimental pragma and 
present it to programmers. If you call it experimental, it's easier for me to 
swallow.


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

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

[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 the vision to get there w/o depending 
on polly. If this is already discussed and settled, pointer to that is 
appreciated so that I can learn.

Thanks,
Hideki


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

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

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

[PATCH] D66199: [docs] loop pragmas

[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



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D66199: [docs] loop pragmas

[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 setting transformation options

and there loop hints ==> and there are loop hints


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D66199/new/

https://reviews.llvm.org/D66199



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[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 practical side. If whatever we decide here changes how the pragma 
behaves from today, we need to have a wider discussion and agreement at 
llvm-dev.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D66796/new/

https://reviews.llvm.org/D66796



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[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 programmers, they don't care LoopVectorize or 
something else. They care about vectorization of loop. So, 2) makes more sense.

If we are providing pragmas for compiler writers, we should be making this more 
like

  #pragma clang loop LoopVectorize(disable)

so that what is controlling what crisply known to everyone.

For anything that is programmer visible, I think it's time for LLVM vectorizer 
to focus on how the programmers use rather than how vectorizer writers think 
about things.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D66796/new/

https://reviews.llvm.org/D66796



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[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 myself to the subscriber.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57978/new/

https://reviews.llvm.org/D57978



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits