sjoerdmeijer commented on pull request #18:
URL: https://github.com/apache/tvm-rfcs/pull/18#issuecomment-910235468
@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?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
