When a libcall will be generated?

Project Infrastructure LLVM Dev List Archives
#1

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

#2

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).

#3

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.