AlexVlx wrote: > This seems like a pretty massive work-around. Could you be more specific > about what the issue is? I'd expect LLVM optimizations to preserve everything > we need, and if they don't it's because we're breaking the rules / overriding > symbols with `-mlink-builtin-bitcode`.
This is not a workaround, it's a "by design" aspect we haven't gotten around to. SPIRV, even when flavoured, is not AMDGCN, so it cannot (and should not) preserve everything we need. Consider vectorisation, or AS inference, target specific types, completely different costing for SROA & friends, different optimal expansions of known patterns etc. At the same time, if we have target (AMDGPU) specific passes that are expected to run before optimisation, they must run on unoptimsed IR. As more SPIR-V specific optimisations get added / enabled, this delta will only increase. On top of this, as it is we're duplicating / doing spurious work by (unintentionally) running passes at least twice, once over pre SPV IR, and once over post SPV IR. https://github.com/llvm/llvm-project/pull/154765 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
