hvdijk added a comment. In D86310#4496582 <https://reviews.llvm.org/D86310#4496582>, @nikic wrote:
> The main problem with that is that we can't have multiple data layouts for > one module, so linking old and new bitcode together would fail. Good point, but it's worth pointing out that this only applies to linking in the LLVM IR sense. Linking in the ELF object file sense would work exactly as it would with the explicit alignments added everywhere, as ELF object files do not contain that data layout string. Linking in the LLVM IR sense is what happens with `clang -flto` though. > But maybe that's exactly what we want -- after all, it is incompatible. Even > if we "correctly" upgraded to preserve behavior of the old bitcode, it would > still be incompatible with the new bitcode if i128 crosses the ABI boundary > (explicitly or implicitly). Yeah, that is a tricky question to answer. Let's say this change goes into LLVM 17, so LLVM 17 X86 data layouts include `i128:128`, and nothing is changed for LLVM 16. Let's also say we have a program made up of two source files, `a.c`, and `b.c`. Then: - `clang-16 -c -flto a.c b.c && clang-17 a.o b.o` should ideally be accepted and would behave in the same way as `clang-16 -c a.c b.c && clang-16 a.o b.o`. - `clang-16 -c -flto a.c && clang-17 -c -flto b.c && clang-17 a.o b.o` should ideally be accepted if neither `a.o` nor `b.o` use CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86310/new/ https://reviews.llvm.org/D86310 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
