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