[PATCH] D106347: [PoC][RISCV] Encode arch information in a new module flag meatadata 'riscv-isa-bits'.

[Zakk Chen via Phabricator via cfe-commits]

khchen created this revision.
khchen added reviewers: jrtc27, MaskRay, kito-cheng.
Herald added subscribers: vkmr, frasercrmck, dexonsmith, evandro, luismarques, apazos, sameer.abuasal, s.egerton, Jim, benna, psnobl, jocewei, PkmX, the_o, brucehoult, MartinMosbeck, rogfer01, edward-jones, zzheng, shiva0217, niosHD, sabuasal, simoncook, johnrusso, rbar, asb, hiraditya.
khchen requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

1. Support a new link behavoir 'OR' for module flag metadata, use for riscv-isa-bits.

(This feature could be in separated patch if PoC patch is workable.)

2. riscv-isa-bits records the march information for a module.

RISCVAsmPrinter reads the riscv-isa-bits to generate corrent arch attribute
if -mattr is missing.

Currently RISC-V encodes arch information per function attribute, 'target-features'.
so there are two issues we want to fix.

1. In IFUNC case (ex. https://godbolt.org/z/a1oTbacn9), the final arch

attribute information is ambiguous because one compilation unit have
different target-feature value in function attribute.
We could not just union of all target-features, because in IFUNC case,
the base arch string is excepted elf arch attribute.

2. During the LTO, clang driver will not pass -march option to LTO code

generator, because users maybe specify the incorrect -march value if
some linked external libraries have been compiled with different arch
extensions.

The probably way is adding a new module flag metadata, riscv-isa-bits, to
records -march info for one compilation unit, and each riscv-isa-bits
get combined (OR) when linking.

In this PoC patch, I think the potential issue is illegal arch combination
will report an error in code generation stage, not in linking stage.
(For example, zfinx is conflict with f/d/q, and Zceb and Zcec are conflict with d)
I'm not sure having a target dependence behaivor in bitcode linking does make
sense or not.

Thanks for @jrtc27, @MaskRay to address this issue in D102926 <https://reviews.llvm.org/D102926> and D102925 <https://reviews.llvm.org/D102925>,
and @kito-cheng's reminder of exclusive extensions issue.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D106347

Files:
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/CodeGenTypeCache.h
  clang/test/CodeGen/RISCV/riscv-metadata-isa-bits-empty-target-feature.cpp
  clang/test/CodeGen/RISCV/riscv-metadata-isa-bits-ifunc.c
  clang/test/CodeGen/RISCV/riscv-metadata-isa-bits.c
  llvm/include/llvm/IR/Module.h
  llvm/include/llvm/Support/RISCVISAInfo.h
  llvm/lib/IR/Verifier.cpp
  llvm/lib/Linker/IRMover.cpp
  llvm/lib/Support/RISCVISAInfo.cpp
  llvm/lib/Target/RISCV/MCTargetDesc/RISCVTargetStreamer.cpp
  llvm/lib/Target/RISCV/MCTargetDesc/RISCVTargetStreamer.h
  llvm/lib/Target/RISCV/RISCVAsmPrinter.cpp
  llvm/test/CodeGen/RISCV/riscv-isa-bits.ll
  llvm/test/Linker/Inputs/module-flags-or-1.ll
  llvm/test/Linker/module-flags-or-1.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D106347.360038.patch
Type: text/x-patch
Size: 22292 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20210720/29252326/attachment-0001.bin>