efriedma added a comment. > So we need to keep ABI in somewhere and read that at LTO phase, the most > ideal place is the module flags. We already did that[6], but that comes with > a problem is it's too late to update datalayout when we start to read a > module, because LLVM will use datalayout to infer some info like the > alignment of loads[7], and that means we might re-read the whole LLVM IR > again to get the IR with the right info, and that requires fixing multiple > places in LLVM (see[2]. Still, I am not sure it's enough or not).
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"? > There is also an issue with how to store and determine the final LTO target > features. For example, A object built with -march=rv64g and B object built > with -march=rv64gc, so which arch should we use in the LTO code generation > stage? see [5] for more discussion around this issue. 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. 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
