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

[Zakk via llvm-dev]

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 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/6584d400/attachment.html>