[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 23:15:42 PDT 2022


efriedma added a comment.

In D132843#3771029 <https://reviews.llvm.org/D132843#3771029>, @jrtc27 wrote:

> In D132843#3770936 <https://reviews.llvm.org/D132843#3770936>, @efriedma wrote:
>
>>> 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.

Oh, I see.  Most other targets don't have ELF attributes like that.  32-bit ARM does, but I'm not sure how the interaction with LTO works there off the top of my head.

We probably want to encode the architecture into the IR in some way that allows us to produce the same attributes whether or not LTO is enabled.


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