beanz added a comment. In D133668#3783489 <https://reviews.llvm.org/D133668#3783489>, @aaron.ballman wrote:
> Okay, that's good to know! If you don't intend to *ever* conform to the > standard in this area, then I think this approach is very reasonable. But you > should know up front that you're constraining yourself here. (Changing the > underlying type in the future is an ABI break: > https://godbolt.org/z/P6ndrzMab, note the name mangling.) We have the benefit of ABI escape hatches. HLSL itself doesn't define a permanently stable ABI since GPU hardware and runtime ABIs change too frequently. We instead revision our ABI every few years as the DirectX and Vulkan specifications evolve. My hope is that as the HLSL language and our runtime ABIs evolve we'll be more and more conformant to the C standard, but there are some odd areas that we might never quite get there on. The 16-bit integer math is an interesting case. Because GPUs are inherently SIMD machines, on many architectures you can handle twice as many 16-bit operations per instruction as 32-bit (yay vectors!). Combine that with HLSL's SPMD programming model and all scalar math is actually vector math. This makes integer promotion for 16-bit types severely limiting. As a result I don't suspect we'll ever want to conform to C here. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D133668/new/ https://reviews.llvm.org/D133668 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
