[PATCH] D132843: [RISCV] Ensure target features get passed to the LTO linker for RISC-V
Eli Friedman via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Mon Sep 5 11:25:14 PDT 2022
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
More information about the cfe-commits
mailing list