[llvm-dev] Encode target-abi into LLVM bitcode for LTO.
David Blaikie via llvm-dev
llvm-dev at lists.llvm.org
Mon Jan 6 14:29:56 PST 2020
On Mon, Jan 6, 2020 at 5:58 AM Zakk <zakk0610 at gmail.com> wrote:
> David Blaikie <dblaikie at gmail.com> 於 2020年1月6日 週一 下午2:23寫道：
>> 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?
> Are you talking about that "[mips] Pass ABI name via -target-abi instead
> of target-features"?
I'm not talking about that patch in particular (I have no specific
knowledge of mips or its implementation) - but speaking about the general
design of LLVM's subtarget features.
Might be interesting to know why that change was made & may help explain
what's going on here.
> I don't know WHY -target-abi is passing via different option, not via
> -mattr (subtarget feature)
> maybe usually subtarget feature is used to manages different specific ISA.
>> 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 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
>>> 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
> Best regards,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev