kito-cheng added a comment. > I'm not sure how the issues with datalayout in particular end up being an > issue in practice. > > clang shouldn't be writing out object files without a datalayout. > The code to infer alignment on load/store/etc. only exists for compatibility > with old bitcode/IR; current LLVM bitcode always marks up alignment for all > operations. > Or do you mean something else when you say "datalayout"?
ilp32/ilp32f/ilp32d and ilp32e(D70401 <https://reviews.llvm.org/D70401>) having different data layout, so when we try to merge those stuffs will run into trouble, although I admit build object file with ilp32/ilp32f/ilp32d then LTO with ilp32e is generally a bad idea. Another issue is the LLVM isn't compatible between different ABI, e.g. ilp32 and ilp32f having different LLVM IR when passing a struct with a int and a float[2]. [1] https://reviews.llvm.org/D71387#1792169 --- > On other targets, the instruction set used is encoded at a per-function > level. So on x86, for example, you can have an "AVX" codepath and an "SSE" > codepath, and use runtime CPU detection to figure out which to use. Give an example to explain what problem we have now and what option we have: $ clang -target riscv64-elf -flto a.c -o a.o -march=rv64gc # a.o build with -march=rv64gc $ clang -target riscv64-elf -flto b.c -o b.o -march=rv64g # b.o build with -march=rv64g $ clang -target riscv64-elf a.o b.o -o a.out -flto -march=rv64gc_zba # and LTO phase use -march=rv64gc_zba, what target feature (or ISA extensions) should be used for all function Possible solution/results: 1. All functions in `a.o` and `b.o` using same target features during the first build stage, `-march=rv64gc` for a.o, `-march=rv64g` for `b.o`, and `-march` option given in LTO CodeGen stage is ignored, it only used for ELF attribute use (this revision). 2. All functions in `a.o` and `b.o` using same target features during the first build stage, `-march=rv64gc` for a.o, `-march=rv64g` for `b.o`, and deduced arch info from those `.o` for ELF attribute use (D106347 <https://reviews.llvm.org/D106347>), `-march` 3. All functions in `a.o` and `b.o` re-compile with `-march=rv64gc_zba` and ELF attribute use `rv64gc_zba`. Option 1: Require user use right `-march` option during LTO stage, and might fill wrong/unexpected ELF attribute if give wrong `-march` or not even not given in LTO stage. Option 2: Should be more ideal, but D106347 <https://reviews.llvm.org/D106347> seems no progress for a while. Option 3: This option will break IFUNC usage. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D132843/new/ https://reviews.llvm.org/D132843 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
