This is an archive of the discontinued LLVM Phabricator instance.

[clang] Loop pragma vectorize(disable)
AbandonedPublic

Authored by SjoerdMeijer on Aug 27 2019, 4:02 AM.

Details

Summary

This changes the behaviour of vectorize(disable). I.e., disabling vectorization
now means disabling vectorization, and not setting the vectorization width to 1.

This is a follow up of the discussion on the behaviour of different loop
pragmas, and that setting transformation options should imply enabling the
transformation, see also
http://lists.llvm.org/pipermail/cfe-dev/2019-August/063054.html.

Not only is this change in the behaviour of vectorize(disable) probably more sensible,
it also helps in implementing options implying transformations.

Diff Detail

Event Timeline

Therefore, vectorize(disable) would also disable interleaving?

Therefore, vectorize(disable) would also disable interleaving?

I don't have strong opinions on this. I think there's something to say for both options that we have (i.e. vectorize(disable) disables interleaving or enables it).
But I think it was @fhahn who mentioned that it would be possible to disable vectorisation, but still do interleaving. Perhaps bit of a edge use use, but again, it's possible currently. That would mean we don't need to disable interleaving here I think.

friendly ping.

Shall we get this in, so that I can commit this and D66290? Then, we can perhaps continue the interleave discussion separately?
I will then return to the doc patch first in D66199, so that we can start wrapping up the loop pragma business, and hopefully it is a lot more consistent!

fhahn added a comment.Sep 9 2019, 10:02 AM

IMO it is fine to say pragma vectorize(disable) disables the vectorizer completely, including interleaving. @Meinersbur, what do you think? I think it would be good to make that clear in the commit message.

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.

SjoerdMeijer added a comment.EditedSep 9 2019, 2:46 PM

Hi Hideki,

I think your comments are spot on:

It all depends on to whom we are providing these pragmas.

Pragma's are user-facing "options" to override or force compiler decision making. I don't think there's another way to look at it, but please correct me if I'm wrong.

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.

And thanks Florian for getting this discussion going again! Will definitely make this clear(er) in this description and commit message once we agree on it.

hsaito added a comment.Sep 9 2019, 5:38 PM

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.

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.

Yep, forgot about that, thanks for the suggestion. I've just posted this message to the list:

http://lists.llvm.org/pipermail/llvm-dev/2019-September/135016.html

SjoerdMeijer abandoned this revision.Sep 13 2019, 12:27 AM

Every day is a school day, and Hal taught me something ;-)

As I wrote in the thread on the llvm dev list, with Hal's explanations, I don't think I have a case for this anymore, and so will abandon it (please let me know if you disagree).

Many thanks for reviewing and the discussions!