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

[David Blaikie via llvm-dev]

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[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
>>>
>>
>
> --
> Best regards,
> Kuan-Hsu
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200106/4d762052/attachment.html>