This is an archive of the discontinued LLVM Phabricator instance.

[Clang][lld][RISCV] Passing 'mattr' to lld/llvmgold
AbandonedPublic

Authored by dtcxzyw on Jul 14 2023, 12:11 PM.

Details

Summary

When building applications with LTO/ThinLTO, lld and llvmgold emit wrong .riscv.attributes sections due to the lack of sub-target features (codegen::getMAttrs() returns empty).
This patch adds a new plugin option mattr for lld and llvmgold, to get right module-level sub-target features for temporary ELF objects generated from llvm bitcode.

I think it is a better solution than merging func-level sub-target features like D142191.

Diff Detail

Event Timeline

dtcxzyw created this revision.Jul 14 2023, 12:11 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 14 2023, 12:11 PM
dtcxzyw requested review of this revision.Jul 14 2023, 12:11 PM

Why do you believe this is better than encoding it in the module's IR like the ABI?

Why do you believe this is better than encoding it in the module's IR like the ABI?

  • There is no module-level metadata for target CPU and sub-target features. So I just think that this patch is better than merging from func-level attributes like D142191.
  • Clang passes -plugin-opt=mcpu to lld. Then lld builds lto::Config using codegen::getCPUStr and codegen::getMAttrs (both get the result from command args). It is taken for granted that clang passes -plugin-opt=mattr down to lld.

If we introduce top-level fields like target cpu and target features, we should modify a lot of things (clang/llvm/lld). It can take a long time to migrate (like opaque pointers).

-mattr is a different syntax than -march that users are used to. Why would we want to expose that? There was previously a proposal for doing this automatically https://reviews.llvm.org/D132843

Why do you believe this is better than encoding it in the module's IR like the ABI?

  • There is no module-level metadata for target CPU and sub-target features. So I just think that this patch is better than merging from func-level attributes like D142191.
  • Clang passes -plugin-opt=mcpu to lld. Then lld builds lto::Config using codegen::getCPUStr and codegen::getMAttrs (both get the result from command args). It is taken for granted that clang passes -plugin-opt=mattr down to lld.

If we introduce top-level fields like target cpu and target features, we should modify a lot of things (clang/llvm/lld). It can take a long time to migrate (like opaque pointers).

You're right it might take time, but we've been saying that's what needs to be done for a year. It might have been done by now if the work had gotten started.

dtcxzyw abandoned this revision.Jul 15 2023, 4:10 AM