AlexVlx wrote: > Let me clarify myself, _BitInt(N) will work with the change, I have no > doubts. But I can imagine a SPIR-V extension to appear that would add support > for 4-bit integers. And I can imagine that we would want to not only be able > to emit 4-bit integers in the frontend, but also allow optimization passes to > emit them. For this it would be nice to have a mechanism that would change > datalayout depending on --spirv-ext (or other option).
IMHO, whilst it is mechanically possible, we should not make DataLayout mutable subject to things like the presence or absence of an extension, that seems like a recipe for subtle pain. It seems preferable (to me) to just have another triple for targets where arbitrary (and possibly weird) bitwidths are native i.e. desirable / optimal. I will note that 4-bit ints are still somewhat natural (we've had nibbles, after all). What motivated this change was the weirder types that obtain without conveying native int widths (`i7`, `i62` for example) which are quite unnatural and poorly handled (last time I checked the Translator didn't like them at all), and which might never be optimal native widths, even on exotic FPGAs. In what regards the example itself, unfortunately (fortunately?), that's an actual bug which is relatively orthogonal to this particular PR, it fails today with vanilla upstream, please see: <https://godbolt.org/z/7aeP797PP>. The wide integer types come from GVN, as part of its Load handling, see `VnCoercion::getStoreValueForLoadHelper`. At a glance, it seems like an issue around handling vec3s, which are odd, but, probably; the BE should probably handle this gracefully rather than errorring out, since it's not a case of doing arithmetic on wide ints, it's just ephemeral manipulation of bits - with emphasis on "at a glance". https://github.com/llvm/llvm-project/pull/110695 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
