1. Support a new link behavoir 'OR' for module flag metadata, useriscv-isa-features records the march information for riscv-isa-bitsa module.
(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 attributeRISCVAsmPrinter reads the riscv-isa-features to generate corrent arch
attribute if -mattr is missing.
Currently RISC-V encodes arch information perin function attribute, 'target-features'.te
'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 in 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
The probably way is adding a new module flag metadata, riscv-isa-bits, tofeatures,
to records -march info for one compilation unit, and each riscv-isa-bits
riscv-isa-features 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 are
conflict with d).
I'm not sure having a target dependence behaivor in bitcode linking does make
make sense or not.
Thanks for @jrtc27, @MaskRay to address this issue in D102926 and D102925,
D102925, and @kito-cheng's reminder of exclusive extensions issue.