[llvm] [DirectX] add support for i64 buffer load/stores (PR #145047)

[Justin Bogner via llvm-commits]

================
@@ -570,22 +588,34 @@ static bool expandTypedBufferLoadIntrinsic(CallInst *Orig) {
     ExtractElements.push_back(
         Builder.CreateExtractElement(Extract, Builder.getInt32(I)));
 
-  // combine into double(s)
+  // combine into double(s) or int64(s)
   Value *Result = PoisonValue::get(BufferTy);
   for (unsigned I = 0; I < ExtractNum; I += 2) {
-    Value *Dbl =
-        Builder.CreateIntrinsic(Builder.getDoubleTy(), Intrinsic::dx_asdouble,
-                                {ExtractElements[I], ExtractElements[I + 1]});
+    Value *Combined = nullptr;
+    if (IsDouble)
+      // For doubles, use dx_asdouble intrinsic
+      Combined =
+          Builder.CreateIntrinsic(Builder.getDoubleTy(), Intrinsic::dx_asdouble,
+                                  {ExtractElements[I], ExtractElements[I + 1]});
+    else
+      Combined = createCombinedi32toi64Expansion(Builder, ExtractElements[I],
+                                                 ExtractElements[I + 1]);
----------------
bogner wrote:

I think you misunderstood my suggestion, or at least I don't think it really improves things much to do it as written here. I was thinking we'd put the logic for combining i32s into *either* a double or an int64 into a function, so here we have a simple:
```c++
  Value *Combined = combineI32s(Builder, ExtractElements[I], ExtractElements[I + 1], /*ToDouble=*/IsDouble);
```
This makes it so that the surrounding logic is all clearly about handling the shared logic, and the small difference in what we emit for the conversion itself is what's abstracted into the function.

This would also apply to `expandTypedBufferStoreIntrinsic`, where we could have some kind of `splitToI32s` along the lines of:
```c++
static std::pair<Value *, Value *> splitToI32s(IRBuilder<> &Builder,
                                               Value *InputVal, bool FromVector,
                                               bool FromDouble);
```

The downside is of course the awkward boolean parameters, but I think the way it breaks the code up simplifies things enough to justify it. If you disagree it's probably okay to just do the expansions inline as you have in the store case.

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