[cfe-dev] Proposed changes to vectorize_width #pragma

[Sjoerd Meijer via cfe-dev]

If you wanted to hint

to the compiler that we should use scalable vectors with my proposal you’d

simply add an extra pragma, i.e.



#clang loop vectorize_predicate(enable) vectorize_width(scalable)

Ah yes, that might have been the thing that I missed, but that would indeed then be equivalent with:

    #clang loop vectorize_predicate(enable) vectorize_style(scalable)

I think that leaves us with 2 options that can express the same things, i.e. change or introduce:

1)
vectorize_width(VF, fixed|scalable)
vectorize_width(fixed|scalable)
vectorize_width(VF)

2)
vectorize_style(fixed|scalable)

And then it's probably more of a style question and not that important if there are no implementation or usability issues overloading vectorize_width.

Cheers,
Sjoerd.

________________________________
From: David Sherwood <David.Sherwood at arm.com>
Sent: 25 November 2020 15:50
To: Sjoerd Meijer <Sjoerd.Meijer at arm.com>; cfe-dev at lists.llvm.org <cfe-dev at lists.llvm.org>
Cc: Paul Walker <Paul.Walker at arm.com>; Sander De Smalen <Sander.DeSmalen at arm.com>
Subject: RE: Proposed changes to vectorize_width #pragma


Hi Sjoerd,



As I understand it the interleave count is orthogonal to the vectorization factor and

one does not imply the other. I think the clang documentation gives an example of

this:



  #pragma clang loop vectorize_width(2)

  #pragma clang loop interleave_count(2)

  for(...) {

    ...

  }



Also, I believe that each pragma that we set is a hint for one unit of the

loop vectorizer. It is true that vectorize_predicate enables vectorization, but

the vectorizer will always choose what it thinks is the most profitable

vectorization factor, which could be fixed or scalable. If you wanted to hint

to the compiler that we should use scalable vectors with my proposal you’d

simply add an extra pragma, i.e.



#clang loop vectorize_predicate(enable) vectorize_width(scalable)



Kind Regards,

David.



From: Sjoerd Meijer <Sjoerd.Meijer at arm.com>
Sent: 25 November 2020 13:14
To: cfe-dev at lists.llvm.org; David Sherwood <David.Sherwood at arm.com>
Subject: Re: Proposed changes to vectorize_width #pragma



Hi David,



Thanks for bringing this up here. We have discussed this already on https://reviews.llvm.org/D89031 and a bit offline, and it would be good to get some other opinions on this too.



What we achieve with this extension is that we can toggle fixed/scalable vectorisation. The proposal is to add this property to vectorize_width, because it kind of defines the VectorType which consists of the elementcount and the scalable/fixed part, which sounds reasonable. However, there are other loop pragmas that (implicitly) enable vectorisation:



#pragma clang loop interleave_count(some-number)



or



#pragma clang loop vectorize_predicate(enable)



for which you may want to toggle fixed|scalable vectorisation. If this is correct, then I think the current proposal/implementation is incomplete and/or inconsistent.



I think your own suggestion was to introduce a vectorization_style(enable|disable) at some point, but my proposal would be to use that instead of adjusting vectorize_width as that would address the issue incompleteness/inconsistency issue. Besides this, but more subjective, I don't see all the new combinations of vectorize_width() as making things clearer:



vectorize_width(VF)

vectorize_width(VF, fixed|scalable)

vectorize_width(fixed|scalable)



Probably the implementation of adding vectorization_style(enable|disable) is easier and less contentious than adjusting an existing one, so all together I don't see why the approach of adjusting vectorize_wdith would be preferred. But I might be wrong, might be missing something, so welcome other views on this.



Cheers,

Sjoerd.



________________________________

From: cfe-dev <cfe-dev-bounces at lists.llvm.org<mailto:cfe-dev-bounces at lists.llvm.org>> on behalf of David Sherwood via cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>>
Sent: 24 November 2020 09:04
To: cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org> <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>>
Subject: [cfe-dev] Proposed changes to vectorize_width #pragma



Hi,



At the moment the vectorize_width(X) #pragma is used to provide hints to LLVM

about which vectorisation factor to use. The unsigned argument ‘X’ used to match

the NumElements property in the VectorType class, however VectorType is now

defined in terms of a ElementCount class.



I’d like to propose an extension to the vectorize_width #pragma that now takes

an optional second parameter of ‘fixed’ or ‘scalable’ that matches up with

ElementCount. When not specified the default value would be ‘fixed’. A few

examples of how this would look like are shown below:



  // Vectorize the loop with <4 x eltty>

  #pragma clang loop vectorize_width(4)

  #pragma clang loop vectorize_width(4, fixed)



  // Vectorize the loop with <vscale x 4 x eltty>

  #pragma clang loop vectorize_width(4, scalable)



As a further extension I’d also like to permit vectorize_width(fixed|scalable) to

allow users to hint at the type of vector used without specifying the

vectorisation factor. Examples of this would be:



  // Vectorize the loop with <N x eltty> for a profitable N

  #pragma clang loop vectorize_width(fixed)



  // Vectorize the loop with <vscale x N x eltty> for a profitable N

  #pragma clang loop vectorize_width(scalable)



Any thoughts you have would be much appreciated!



Kind Regards,

David Sherwood.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20201125/5a987070/attachment-0001.html>