smeijer1234 commented on pull request #18:
URL: https://github.com/apache/tvm-rfcs/pull/18#issuecomment-952735188


   A belated thank you for sharing further thoughts on this @tqchen and 
@kparzysz-quic . I am on holiday this week (and a little bit of next), but want 
to pick this up soon after that. In the mean time, some remarks/questions from 
my side.
   
   First of all, the ABI discussion goes over my head at the moment to be 
honest; I am not familiar enough yet to comment or address this. My 
understanding from the discussion so far is, that there will be an ABI break, 
but it is rather limited. So that doesn't require any further attention here, 
would that be a correct summary?
   
   Perhaps more fundamental is @kparzysz-quic 's remark:
   
   > This RFC is not about SVE. It's about vectorizing (countable) loops with 
bounds not known at compile time. I think that would be very valuable for all 
targets and we can determine the list of necessary features that a target 
should satisfy to implement it.
   > 
   > Even though SVE can be used to implement it, it only applies to ARM, and 
there is no compelling reason to introduce SVE-specific features to TIR. There 
may be room for unknown-length vectors in TIR, but that should be done 
separately from SVE.
   
   Yep, I agree, and you're right about this: this is not really about SVE. The 
"only" addition to TIR is the `is_scalable` part, which I would not consider to 
be SVE-specific, because it indeed just represents an unknown length vector and 
any back-end can deal with that in any way they like (and there are quite a few 
architectures that now support scalable-like vectors). So just for my 
understanding, would you mind elaborating on your thoughts here? For example, 
is it just a naming issue and we need to find another term, or is it more 
fundamental how we would like to do things in TIR? Thanks! 
   


-- 
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]


Reply via email to