[PATCH] D116362: [TTI] Support ScalableVectorType in getShuffleCost with SK_Broadcast kind
JunMa via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Jan 3 19:12:28 PST 2022
junparser added inline comments.
================
Comment at: llvm/include/llvm/CodeGen/BasicTTIImpl.h:881
case TTI::SK_Broadcast:
- return getBroadcastShuffleOverhead(cast<FixedVectorType>(Tp));
+ return getBroadcastShuffleOverhead(Tp);
case TTI::SK_Select:
----------------
paulwalker-arm wrote:
> Based on the above personally I think `getShuffleCost` is wholly unsafe for scalable vector shuffles and I'd sooner see the "you probably didn't want to get here" code here. For example:
> ```
> case TTI::SK_Broadcast:
> if (!isa<FixedVectorType>(Tp))
> return InstructionCost::getInvalid();
> return getBroadcastShuffleOverhead(cast<FixedVectorType>(Tp));
> ```
> This for me makes it clearer that if you'd rather not return an invalid cost then you'll need to fix the target specific implementation of this function.
>
> Presumably the other shuffle types below need the same treatment?
> Based on the above personally I think `getShuffleCost` is wholly unsafe for scalable vector shuffles and I'd sooner see the "you probably didn't want to get here" code here. For example:
> ```
> case TTI::SK_Broadcast:
> if (!isa<FixedVectorType>(Tp))
> return InstructionCost::getInvalid();
> return getBroadcastShuffleOverhead(cast<FixedVectorType>(Tp));
> ```
> This for me makes it clearer that if you'd rather not return an invalid cost then you'll need to fix the target specific implementation of this function.
>
make sense to me.
> Presumably the other shuffle types below need the same treatment?
Yes, we also need handle intrinsic like vector.reverse with scalable vector.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D116362/new/
https://reviews.llvm.org/D116362
More information about the llvm-commits
mailing list