llvm dev - Jan 2020 - Encode target-abi into LLVM bitcode for LTO.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200106/b4d75632/attachment.html>

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>

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>