Since shufflevector supports scalable vector in broadcast mode, it
should be handled as well in getShuffleCost. This patch does this which fixes
assertion in https://github.com/llvm/llvm-project/issues/51550,
TestPlan: check-llvm
Differential D116362
[TTI] Support ScalableVectorType in getShuffleCost with SK_Broadcast kind junparser on Dec 28 2021, 11:31 PM. Authored by
Details Since shufflevector supports scalable vector in broadcast mode, it TestPlan: check-llvm
Diff Detail
Unit Tests
Event TimelineComment Actions It's fine to have a vectorizer test, but it would be better to have a more direct test of the cost model itself. I think something like this can check for the crash (we could add variations to see if the cost is actually accurate - see /llvm/test/Analysis/CostModel/AArch64/sve-shuffle-broadcast.ll for an existing test model): ; RUN: opt -cost-model -analyze -mtriple=riscv64 -mattr=+m,+experimental-v -scalable-vectorization=on < %s | FileCheck %s define void @broadcast() { %zero = shufflevector <vscale x 16 x i8> undef, <vscale x 16 x i8> undef, <vscale x 16 x i32> zeroinitializer ret void }
Comment Actions good point, I missed this because of that rv does not have such target api. I'll add it.
Comment Actions This looks like it would treat the default cost of a broadcast as scalarising the first n elements from a <vscale x n x iM> vector, which doesn't sound right. Unless we are assuming that the default vscale is 1. I would suspect that the cost should either be invalid or to be "cheap" under assumption that the operation is always present. AArch64 has some cost overrides in its backend for certain types of scalable broadcasts.
Comment Actions Yes, This patch keeps same behavior as before (release mode).
without target override,we cannot compute scalable vector broadcasts here. So I think set invalid for scalabe vector here make sense.
|
clang-format not found in user’s local PATH; not linting file.