riscv-isa-features records the march information for a module.
RISCVAsmPrinter reads the riscv-isa-features to generate corrent arch
attribute if -mattr is missing.
Currently RISC-V encodes arch information in function attribute
'target-features', so there are two issues we want to fix.
- 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.
- 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-features,
to records -march info for one compilation unit, and each
riscv-isa-features get combined 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 and
D102925, and @kito-cheng's reminder of exclusive extensions issue.
Why is this building a list? Just use a string so it's in the same format as the function attributes? We already have parsers for that. Yes, it means you do a small amount of redundant work but having a single format in the IR for representing the same thing in every place is better than having multiple different ways of representing the same thing.