There are two steps in LTO codegen so the problem is how to pass ABI info into LTO code generator.
The easier way is pass -target-abi via option to LTO codegen, but there is linking issue when linking two bitcodes generated by different -mabi option. (see https://reviews.llvm.org/D71387#1792169)
Usually the ABI info for a file is derived from target triple, mcpu or -mabi, but in RISC-V, target-abi is only derived from -mabi and -mattr option, so the one of solutions is encoding target-abi in IR via LLVM module flags metadata.
But there is an another issue in assembler. In current LLVM design, there is no mechanism to extract info from IR before AsmBackend construction, so I use some little weird approach to init target-abi option before construct AsmBackend or reassign target-abi option in getSubtargetImpl and do some hack in backend.
- https://reviews.llvm.org/D72245#change-sHyISc6hOqcy (see llc.cpp)
- https://reviews.llvm.org/D72246 (see RISCVAsmBackend.h)
I think  and  are not good enough, the other ideals like
encode target abi info in triple name. ex. riscv64-unknown-elf-lp64d
encode target-abi into in target-feature (maybe it’s not a good ideal because mips reverted this approach
users should pass target-abi themselves. (append -Wl,-plugin-opt=-target-abi=ipl32f when compiling with -mabi=ilp32f)
Is it a good idea to encode target-abi into bitcode?
If yes, is there another good approach to fix AsmBackend issue?
I’d appreciate any help or suggestions.