Re: [apache/tvm-rfcs] [RFC] Adding initial SVE implementation (#18)

[sjoerdmeijer <no...@github.com.INVALID>]

@masahi, about: 
 
> If possible, I think it is better not to introduce user facing changes, since as far as an API is concerned, `s[C].vectorize(...)` is already vector-length agnostic.

which I think is very closely related to an earlier inline comment:

> As I commented above, I'd like to continue using s[C].vectorize(...) and when the feature is available, enable SVE by a target attribute. So I don't expect any user facing work.

I think we do need a user-facing option to toggle fixed/scalable vectorisation. If the vectorisation strategy is selected based on an available target attribute, we loose control to choose fixed/scalable vectorisation. For architectures that do support scalable vectorisation, fixed width might still be preferable in some cases.

I think this is similar to Clang's loop pragmas. For example, the `vectorise_width` pragma has been extended with an optional second argument `fixed|scalable`:

`vectorize_width(_value_[, fixed|scalable]),`

see also the Clang docs [here](https://clang.llvm.org/docs/LanguageExtensions.html#extensions-for-loop-hint-optimizations).

So I see two approaches:
- we extend `s[C].vectorize(...)` to take an optional fixed/scalable boolean value, similar to Clang's loop pragma, which defaults to fixed if omitted, 
- or introduce `s[C].vectorize_scalable(...)` as proposed in this RFC.

I personally don't have any preference. But now I am wondering if extending `s[C].vectorize(...)`, the first option, would be better. What do you think?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/18#issuecomment-910235468