spall wrote: > It is not correct to limit firstbithigh to 32 bit integers. There are a > couple of reasons that might make one think that it is, but we do in fact > want/need to support int16 and int64 here. > > 1. The [HLSL > docs](https://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/firstbithigh) > only mention integer. Unfortunately that's true for most of these functions, > as many of these docs were not updated as 64 and 16 bit types gained support > in the language. > If you click through the definition of Int it defines it to be 32 bits. > 2. DXC's SPIR-V implementation doesn't handle 16- and 64-bit for these > functions. As noted in [Incorrect SPIR-V generated when `firstbithigh` is > used on a `uint64_t` > microsoft/DirectXShaderCompiler#4702](https://github.com/microsoft/DirectXShaderCompiler/issues/4702) > we decided not to implement those overloads in DXC, but should reconsider > this for clang. > > > Despite all of this, DXC does indeed support 16- and 64-bit overloads, as > seen here: https://hlsl.godbolt.org/z/qbc17xz35 > > Note that the return type of the operation is not overloaded - all of the > overloads of this function return uint.
https://github.com/microsoft/DirectXShaderCompiler/blob/main/docs/DXIL.rst#firstbithi FirstBitHi does explicitly mention only 32 bit integers. https://github.com/llvm/llvm-project/pull/111082 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
