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

Farzon Lotfi via llvm-commits llvm-commits at lists.llvm.org
Fri Jun 27 10:08:27 PDT 2025


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

I don't agree, I prefer if helper functions have as little branching behavior as possible. For me personally it makes it easier when I'm debugging and expansion like this one if I can assume  one block of code gets generated and I don't have to step into a helper to know which branch is taken. I also like to keep intrinsic creation for dx_asdouble in the `expandTypedBufferLoadIntrinsic.` Because thats kind of the whole point of this expansion for the double case and abstracting the logic out to a helper makes  the code harder to read  because its not linear. So when you are trying to understand whats going on you have to context switch to a new function. I think the current helper is a good compromise you can see the double logic and understand that the i64 case performs a similar function.

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


More information about the llvm-commits mailing list