rjmccall added a comment. In D133668#3847807 <https://reviews.llvm.org/D133668#3847807>, @beanz wrote:
> 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. But that's purely on the implementation level, right? Everything is implicitly vectorized and you're just specifying the computation of a single lane, but as far as that lane-wise computation is concerned, you just have expressions which produce scalar values. > 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. If you don't otherwise have 16-bit (or 8-bit?) types, and it's the type behavior you want, I'm fine with you just using `_BitInt`. I just want to make sure I understand the situation well enough to feel confident that you've considered the alternatives. 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
