[clang] [llvm] [clang][llvm][SPIR-V] Explicitly encode native integer widths for SPIR-V (PR #110695)

[Dmitry Sidorov via llvm-commits]

MrSidims wrote:

> with vanilla upstream, please see

You mean the translator, right? I don't think that SPIR-V backend should follow its practices especially when we could do better.

> 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

So we both agree, that the compiler must compile the OpenCL code from above to SPIR-V without erroring out. We can do it in  2 ways:
1. Regularize types in the backend (since the backend is based on top of global isel we should have here better luck then in the translator);
2. Or since this patch modifies datalayout - adjust LLVM pipeline to consider datalayout in optimization passes. The reasoning you have provided in the PR description: "`This is problematic as it leads to optimisation passes, such as InstCombine, getting ideas and e.g. shrinking to non byte-multiple integer types, which is not desirable and can lead to breakage further down in the toolchain.`" totally makes sense to me. So I'm asking if you have plans to go through the passes and modify them, or you only intend to modify InstCombine and/or AMD-specific passes?



https://github.com/llvm/llvm-project/pull/110695