[llvm] [NFCI][Analysis] Extract alloca slice analysis from SROA (PR #179593)

Jameson Nash via llvm-commits llvm-commits at lists.llvm.org
Sat Feb 7 12:11:45 PST 2026


vtjnash wrote:

I tried to convert DXIL to this, but the solution didn't make any sense to me. The documentation for DXIL seems to suggest that the backend will eventually require that all GEP be converted to ptradd, since non-legacy IR are expected to use ByteAddressBuffer (https://github.com/microsoft/DirectXShaderCompiler/wiki/ByteAddressBuffer-Load-Store-Additions) which seems to only defines byte offset support. However, currently the DXIL target pass is going through a tremendous amount of effort to rewrite any byte indexing into non-byte indexing. But if LLVM didn't have GEP and didn't have getAllocatedType, then many DXIL passes would seem to simply go away, since opaque pointers would simply become byte pointers.

SPIR-V has a fairly similar question, since it too has a ptradd instruction (OpPtrAccessChain), though more understandable why it would take the effort to avoid it when feasible, since it requires capabilities: "Addresses, VariablePointers, VariablePointersStorageBuffer, PhysicalStorageBufferAddresses". I found when trying to convert this SPIRV and DXIL code to use this pass that my biggest problem was actually the existence of typed GEP. With only ptradd, the pass to compute the optimal typed GEP placement would have been fairly trivial, but with typed GEP, the code has to first convert the typed GEP into ptradd to remove the bad / non-semantic type information from them, then recreate them as typed GEP to then reintroduce that type information. That is an IR optimization that seems it would be a whole lot more straightforward to implement once LLVM can rid itself of all typed GEP like instructions and work uniformly with byte pointers.

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


More information about the llvm-commits mailing list