[llvm-dev] Encode target-abi into LLVM bitcode for LTO.

Zakk via llvm-dev llvm-dev at lists.llvm.org
Sun Jan 5 22:03:42 PST 2020


Hi all.

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[1] or reassign target-abi option in getSubtargetImpl and do some
hack in backend[2].

1. https://reviews.llvm.org/D72245#change-sHyISc6hOqcy (see llc.cpp)
2. https://reviews.llvm.org/D72246 (see RISCVAsmBackend.h)

I think [1] and [2] are not good enough, the other ideals like

3. encode target abi info in triple name. ex. riscv64-unknown-elf-lp64d
4. encode target-abi into in target-feature (maybe it's not a good ideal
because mips reverted this approach
before. http://llvm.org/viewvc/llvm-project?view=revision&revision=227583)

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

Thanks.

-- 
Best regards,
Kuan-Hsu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200106/b4d75632/attachment.html>


More information about the llvm-dev mailing list