[llvm] [Scalarizer][DirectX] support structs return types (PR #111569)

[Tex Riddell via llvm-commits]

================
@@ -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));
----------------
tex3d wrote:

I too have a distaste for this particular property lookup pattern, as I've expressed before.  I think these should be properties defined in the intrinsic tablegen file.  Perhaps an intrinsic (vectorization) property struct/object could be defined from that and retrieved (through TTI as necessary), eliminating the need for plumbing attribute properties one by one.

> Third i don't agree with this being a heuristic.

The code was guessing whether a type is added to the overload types based on whether it was different from the previous type.  That's the heuristic.  If the types matched, that doesn't mean that the type is not used in the overload (in the general sense).

https://github.com/llvm/llvm-project/pull/111569