beanz added a comment. In D133668#3847163 <https://reviews.llvm.org/D133668#3847163>, @rjmccall wrote:
> Sure, but it's extremely easy to unpromote that arithmetic for most > operators, and I'm sure LLVM already has a pass that will do that. Okay... but HLSL explicitly doesn't promote. Having the compiler rely on an optimization to generate correct code is undesirable. Especially since we want debug builds to behave correctly. > Alternatively, if you're worried about your ability to unpromote, and since > you're breaking strict conformance anyway, have you considered just removing > the initial promotion to `int` from the usual arithmetic conversions? I'm > pretty sure the rest of the rules hang together just fine if you do. Then > you have a uniform rule that permits easier vectorization for all small > integer types rather than being sensitive specifically to using the `int16_t` > typedef. HLSL isn't conformant to C or C++. One of the big areas that things get wonky is that every `int` is actually an implicit SIMD vector of a hardware-determined size. We could disable promotion for HLSL. That is what we do in DXC. Part of what made me think `BitInt` was a better solution is that HLSL doesn't have the `short` keyword at all. The only 16-bit int types we support are the `[u]int16_t` explicit-sized typedefs. If you think disabling promotion under the HLSL language mode is a better approach, we can do that instead. 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
