[PATCH] D102394: [LoopVectorize] Don't attempt to widen certain calls for scalable vectors

David Sherwood via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed May 19 08:00:34 PDT 2021


david-arm marked 3 inline comments as done.
david-arm added inline comments.


================
Comment at: llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:5672
+        Intrinsic::ID VecID = getVectorIntrinsicIDForCall(CI, TLI);
+        if (VecID && VFDatabase::getMappings(*CI).empty() &&
+            !TTI.isLegalVectorIntrinsic(VecID, VF)) {
----------------
kmclaughlin wrote:
> Hi @david-arm, is it possible for there to be a VecID but getMappings(*CI) is not empty? Is it worth adding a comment about what should happen in this case?
Yeah, so in the majority of cases I expect we don't have mappings for things like `sqrt` and `sin` intrinsics, at least not until there is some scalable vector library support. I've tried to restructure the code here to make the logic a bit clearer.


================
Comment at: llvm/test/Transforms/LoopVectorize/AArch64/scalable-call.ll:124
+
+define void @vec_sqrt_no_mapping(float* noalias nocapture %dst, float* noalias nocapture readonly %src, i64 %n) #0 {
+; CHECK: @vec_sqrt_no_mapping
----------------
kmclaughlin wrote:
> nit: should this test be also be called `no_mapping` if it is legal to vectorize?
Hi @kmclaughlin, so in this case there are no mappings attached to the call instruction, however it is legal to vectorise because there is hardware support for it. I've added comments that hopefully explains it better!


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D102394/new/

https://reviews.llvm.org/D102394



More information about the llvm-commits mailing list