@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
