[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