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

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>

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>

> On Jan 6, 2020, at 14:29, David Blaikie via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 
> 
> On Mon, Jan 6, 2020 at 5:58 AM Zakk <zakk0610 at gmail.com
<mailto:zakk0610 at gmail.com>> wrote:
> 
> 
> David Blaikie <dblaikie at gmail.com <mailto: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.
It's been a while so I don't remember the detail but IIRC one of the
reasons was that mips had a feature bit per ABI and had a lot of duplicated code
sanity checking that only one bit was enabled and deriving the ABI from the
feature bits. The -target-abi option already existed and using that prevented
the possibility of having more than one ABI selected.

There was a lot of code (some of which didn't have access to target
features) in the backend that tried to derive the ABI from the arch component of
the triple (e.g. mips64 => n64 ABI) even though there were multiple possible
ABI's for each arch (mips64 => o32, n32, or n64 ABI's) and there
isn't a canonical choice for any given triple (it varies between linux
distributions and toolchains in general). Settling on -target-abi allowed us to
sort out the inconsistencies in the backends opinion of what the selected ABI
was. It also allowed us to move the selection of the ABI into the frontend where
disagreements between distributions/toolchains on what each triple means was
easier to deal with.
> 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 <mailto: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
<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
<https://reviews.llvm.org/D72245#change-sHyISc6hOqcy> (see llc.cpp)
> 2. https://reviews.llvm.org/D72246 <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
<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 <mailto:llvm-dev at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> 
> 
> -- 
> 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/20200106/3f972f9d/attachment.html>