[llvm-dev] When a libcall will be generated?

[Nemanja Ivanovic via llvm-dev]

Re-adding llvm-dev.

I think that calling a library routine if a target doesn't have a shift
operation is quite reasonable. I'd imagine it would be tricky to transform
the SDAG to get the semantics of a shift in a completely target-independent
fashion.

The actual libcall likely exists in one of the libraries that ship with
LLVM and you'd just have to link with that (I imagine it would be
compiler-rt).

Just grepping in there certainly finds it in:
projects/compiler-rt/lib/builtins/lshrdi3.c.

On Wed, May 31, 2017 at 2:18 PM, 陳韋任 <chenwj.cs97g at g2.nctu.edu.tw> wrote:

> Hi Nemanja,
>
>   Thanks for your input. I get the same conclusion after reading the
> source code for my particular case.
> Yes, the libcall occurred during type legalization. For my case,
> it's DAGTypeLegalizer::ExpandIntRes_Shift [1].
> If the target doesn't support such case, the type legalizer will try to
> emit libcall if there is one (TLI.getLibcallName(LC) != nullptr).
>
>     if (LC != RTLIB::UNKNOWN_LIBCALL && TLI.getLibcallName(LC)) {
>       SDValue Ops[2] = { N->getOperand(0), N->getOperand(1) };
>       SplitInteger(TLI.makeLibCall(DAG, LC, VT, Ops, isSigned, dl).first,
> Lo, Hi);
>       return;
>     }
>
>     if (!ExpandShiftWithUnknownAmountBit(N, Lo, Hi))
>       llvm_unreachable("Unsupported shift!");
>
> I think either we provide the corresponding libcall in libgcc, or make
> proper handling elsewhere in the
> type legalizer.
>
> [1] http://llvm.org/doxygen/LegalizeIntegerTypes_8cpp_source.html
>
> Regards,
> chenwj
>
>
> 2017-05-29 20:41 GMT+08:00 Nemanja Ivanovic <nemanja.i.ibm at gmail.com>:
>
>> If I'm not mistaken, legalization will introduce the libcalls as per the
>> call to `InitLibcallNames()` in `TargetLoweringBase::TargetLoweringBase()`
>> (or anything your target overrides). This would seem to imply that your
>> target doesn't have i64 as a legal type (or at the very least,
>> shift-right-logical is not legal for i64 types on your target).
>>
>> For an example of how this ends up in the code, you can compile a program
>> such as this with triple -mtriple=powerpc64le-unknown-unknown
>> ```
>> define ppc_fp128 @test(ppc_fp128 %a, ppc_fp128 %b) {
>> entry:
>>   %add = fadd ppc_fp128 %a, %b
>>   ret ppc_fp128 %add
>> }
>> ```
>> You can see when the result type of the `fadd` is legalized, a libcall is
>> added to the SDAG (since ppcf128 is not a legal type - no registers on PPC
>> for it).
>>
>> I hope this helps (and I hope I'm not misleading you here).
>>
>> On Fri, May 19, 2017 at 9:44 AM, 陳韋任 via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> Hi All,
>>>
>>>   I am looking at a linker error under O2:
>>>
>>>      undefined symbol __lshrdi3
>>>
>>> I have two questions here:
>>>
>>>   1. Does that mean our libgcc (?) doesn't implement __lshrdi3? Or more
>>> generally, why I have
>>>       such linker error?
>>>
>>>   2. Seems some operations are combined, and replaced with __lshrdi3
>>> call. I am interested in
>>>       when such libcall will be generated? Could you show me one
>>> example so that I can trace
>>>       the LLVM source code on my own?
>>>
>>> Thanks.
>>>
>>> Regards,
>>> chenwj
>>>
>>> --
>>> Wei-Ren Chen (陳韋任)
>>> Homepage: https://people.cs.nctu.edu.tw/~chenwj
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>>
>>
>
>
> --
> Wei-Ren Chen (陳韋任)
> Homepage: https://people.cs.nctu.edu.tw/~chenwj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170531/2ce23a4b/attachment.html>