jrtc27 added a comment. In D132843#3770936 <https://reviews.llvm.org/D132843#3770936>, @efriedma wrote:
>> 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. Maybe for IR DataLayout upgrades, but those are rather rare. > - 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. The IR records that too, but the "default" set of extensions gets encoded in the output file so loaders can know what instruction sets are _required_ (as opposed to optional via IFUNCs). It's not a perfect match, but it's about as good as you can get. With GNU ld these get merged together, though currently LLD just picks the one from the first file and ignores the rest (I think?); ideally the LLVM module linker would do similar merging. 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
