[cfe-dev] Proposed changes to vectorize_width #pragma

[Roger Ferrer Ibáñez via cfe-dev]

Hi David,

Thanks a lot for the clarification.

Defaulting to fixed vectorization and having a qualifier that restricts to
fixed/scalable vectorization seems very reasonable to me in this context. I
can see how a `vectorize_style(any)` would be unnecessary.

Kind regards,

Missatge de David Sherwood <David.Sherwood at arm.com> del dia dc., 9 de des.
2020 a les 13:49:

> Hi Roger,
>
>
>
> Thanks for the suggestion. With regards to possible use cases of a
> vectorize_style(any)
>
> pragma my thoughts are:
>
>
>
> 1. Any existing tests that currently use vectorize_width(#number) were
> presumably
>
> written with fixed width vectorisation in mind. So it makes sense in those
> cases
>
> for the default to be fixed width. If the user wants to go back and fix
> them to explicitly
>
> use scalable vectorisation they can just add vectorize_width(#number,
> scalable). We
>
> feel that specifying the numeric part of the vectorisation factor without
> also considering
>
> if the factor is fixed-length or scalable is not a realistic/real world
> use case. I imagine
>
> that best results will be obtained by letting the vectoriser choose the
> best pair, i.e.
>
> vectorize_width(4, fixed) or vectorize_width(8, scalable).
>
> 2. However, if the user wants the compiler to choose the best option
> (fixed or scalable)
>
> then we already have a route for that with vectorize(enable). Similarly
> when compiling
>
> at -O2 or above the compiler will choose the most profitable option.
>
>
>
> Kind Regards,
>
> David.
>
>
>
> *From:* Roger Ferrer Ibáñez <rofirrim at gmail.com>
> *Sent:* 30 November 2020 13:34
> *To:* David Sherwood <David.Sherwood at arm.com>
> *Cc:* cfe-dev at lists.llvm.org
> *Subject:* Re: [cfe-dev] Proposed changes to vectorize_width #pragma
>
>
>
> Hi David,
>
>
>
> Your proposal looks sensible to me. I understand that for reasons of
> evolution of the pragma, you chose to give it `fixed` semantics if no
> explicit mark of vectorisation style appears, right?
>
>
>
> Is this something in the future we'd want to relax? This way the target
> could also pick the best vectorization style (borrowing Sjoerd's
> terminology here).
>
> Perhaps we could define a `vectorize_style(any)` as well. That would be
> the one used if no explicit `vectorize_style` is specified.
>
>
>
>
>
> 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)
>
> In those cases, I imagine `vectorize_style` could be enough and we avoid
> having a `vectorize_width` that doesn't actually tell us the width (or the
> factor of the actual width, for scalables). But this falls in the
> "aesthetics" category, I think.
>
>
>
> Kind regards,
>


-- 
Roger Ferrer Ibáñez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20201209/0e9e94df/attachment.html>