[cfe-dev] Proposed changes to vectorize_width #pragma

[Michael Kruse via cfe-dev]

Is "style" the right terminology? Since it affects semantics, I would
prefer some other terminology.

how about vectorize_scalable(enable|disable)?

Michael


Am Mi., 25. Nov. 2020 um 07:18 Uhr schrieb Sjoerd Meijer via cfe-dev
<cfe-dev at lists.llvm.org>:
>
> One typo fixed inline
>
> 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,
>
> I meant vectorization_style(fixed|scalable)
>
> 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> on behalf of David Sherwood via cfe-dev <cfe-dev at lists.llvm.org>
> Sent: 24 November 2020 09:04
> To: cfe-dev at lists.llvm.org <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.
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev