[llvm] [Scalarizer][DirectX] support structs return types (PR #111569)
Justin Bogner via llvm-commits
llvm-commits at lists.llvm.org
Thu Oct 17 15:06:09 PDT 2024
================
@@ -667,14 +686,26 @@ bool ScalarizerVisitor::splitBinary(Instruction &I, const Splitter &Split) {
bool ScalarizerVisitor::isTriviallyScalarizable(Intrinsic::ID ID) {
if (isTriviallyVectorizable(ID))
return true;
+ // TODO: Move frexp to isTriviallyVectorizable.
+ // https://github.com/llvm/llvm-project/issues/112408
+ switch (ID) {
+ case Intrinsic::frexp:
+ return true;
+ }
return Intrinsic::isTargetIntrinsic(ID) &&
TTI->isTargetIntrinsicTriviallyScalarizable(ID);
}
/// If a call to a vector typed intrinsic function, split into a scalar call per
/// element if possible for the intrinsic.
bool ScalarizerVisitor::splitCall(CallInst &CI) {
- std::optional<VectorSplit> VS = getVectorSplit(CI.getType());
+ Type *CallType = CI.getType();
+ bool AreAllMatchingVectors = isStructOfMatchingFixedVectors(CallType);
+ std::optional<VectorSplit> VS;
+ if (AreAllMatchingVectors)
+ VS = getVectorSplit(CallType->getContainedType(0));
----------------
bogner wrote:
I think that limiting our handling to cases where all of the vector types nested in the struct type of the return type match is pretty reasonable. Adding handling for cases where we have overloads in some subset of the return types seems like it would be quite complicated and I can't really come up with a realistic scenario where it might happen. The fact that the only intrinsic that exists today that has special treatment of the return type at all is `is_fpclass` is probably evidence that this is rare.
I do think a comment and/or an assert if we find that the vector types of the returned struct type mismatch is appropriate, but let's not go overboard and implement a fully generic solution for something that we only have theoretical evidence for being a problem.
https://github.com/llvm/llvm-project/pull/111569
More information about the llvm-commits
mailing list