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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
