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

[David Blaikie via llvm-dev]

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>
wrote:

> 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
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200105/1cfd9135/attachment.html>