Change Details

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 and D102925, and @kito-cheng's reminder of exclusive extensions issue.

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. 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 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.

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 extensions. 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.