[llvm-dev] Encode target-abi into LLVM bitcode for LTO.
David Blaikie via llvm-dev
llvm-dev at lists.llvm.org
Sun Jan 5 22:23:46 PST 2020
If this is something that can vary per file in a compilation and resolve
correctly when one object file is built with one ABI and another object
file is built with a different ABI (that seems to be antithetical to the
concept of "ABI" Though) - then it should be a subtarget feature.
ABI is generally something that has to be agreed upon across object files -
so it wouldn't make sense to link two object files with two different ABIs.
What's going on here that makes that valid in this case?
On Sun, Jan 5, 2020 at 10:04 PM Zakk via llvm-dev <llvm-dev at lists.llvm.org>
> 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 or reassign target-abi option in getSubtargetImpl and do some
> hack in backend.
> 1. https://reviews.llvm.org/D72245#change-sHyISc6hOqcy (see llc.cpp)
> 2. https://reviews.llvm.org/D72246 (see RISCVAsmBackend.h)
> I think  and  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.
> Best regards,
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev