D72768 allows users to give an empty target-abi option with non-empty
target-abi module flag in IR, because we attempts to allowing module flag
to overwrite the empty target-abi options (D72624).
ps. It's worth mentioning that datalayout tends to change for different ABIs.
After digging more into LLVM TargetMahcine design, and as @efriedma mention in
https://reviews.llvm.org/D71387#1788472, overwrite the ABI/datalayout in
TargetMachine or a bitcode file is not easy and it will generate wrong code.
(For example, IR parser supports a datalayout callback which's used to compute
a correct datalayout during the IR parsing, see D78403 for more detal. So if
we want to read the ABI/datalayout info from IR first, it seems we need to
parse the IR twice times, it does not make sense for me.)
In this situation, I think probably reporting a error when the default ABI from empty target-abi option
mismatch with target-abi module flag.
This changed requires users need to specific -target-abi option if IR has
-target-abi module flag if default is mismatch.
In other words, for enabling LTO in RISC-V, clang driver must to forward the
target-abi option into LTO code generator.
ps. The checking routine only exists in the RISC-V back-end now because only
RISC-V will generate -target-abi module flag.
Reference: https://lists.llvm.org/pipermail/llvm-dev/2020-January/138450.html
Is ABIName still the right name here since it isn't a string?