You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tvm.apache.org by GitBox <gi...@apache.org> on 2021/09/01 12:27:08 UTC

[GitHub] [tvm-rfcs] sjoerdmeijer commented on pull request #18: [RFC] Adding initial SVE implementation

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: commits-unsubscribe@tvm.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org