[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