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

Alex Voicu via cfe-commits cfe-commits at lists.llvm.org
Mon Oct 7 14:39:33 PDT 2024


AlexVlx wrote:

> 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?

Wel, the issue the example illustrates is pre-existing and not influenced / triggered by this patch; stepping back, if the question is “are you going to try / would you like to fix this other issue” the answer is yes, but sadly I don't have an immediate intuition as to the right solution (1 is ~approx~ what we do on the AMDGPU side, where we e.g. handle accesses to i128 as the corresponding vec4 access).

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


More information about the cfe-commits mailing list