aaron.ballman added a comment. In D133668#3783975 <https://reviews.llvm.org/D133668#3783975>, @beanz wrote:
> 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. Ah, good to know! Btw, it looks like precommit CI is finding failures 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
