llvm dev - Mar 2018 - LLVM gold plugin do not add llvm instrinsics symbols to the linker symbol table

Hello Teresa,
> Without -flto, a.o ends up with a reference to __exp_finite,
That’s correct.
> which also would not be satifisfied out of libexp.a.
That’s not correct. Even if libexp.a would have __exp_finite, it wouldn’t be
resolved from libexp.a, because of the behavior described in my first message.
> Do you also have an implementation of __exp_finite in your libexp.a?
No, I don’t have __exp_finite in libexp.a. I presented complete code in my first
message. You can reproduce it yourself on current trunk.
> Can you build with -fno-builtin, or -fno-builtin-exp etc?
> That results in a reference to __exp_finite in the .o bitcode
> (which of course has the same issue I mentioned above, but is consistent).
> That seems to be the option you should use here when you want to use your
own implementations.
Yes, -fno-builtin results in call to __exp_finite in the bitcode. But the
problem I try to address is not what version of exp libcall we want to generate:
exp or __exp_finite.
The problem is that if the exp call was lowered to llvm intrinsic, linker
doesn’t resolve it from my static library in LTO build, because plugin
(LLVMgold.so) doesn’t report those symbols (yet in intrinsic form) to the
linker.

Best regards,
Denis Bakhvalov.
--------------------------------------------------------------------

Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial
Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 |
Kapital zakladowy 200.000 PLN.

Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i
moze zawierac informacje poufne. W razie przypadkowego otrzymania tej
wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie;
jakiekolwiek
przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). If you are not the intended recipient, please
contact the sender and delete all copies; any review or distribution by
others is strictly prohibited.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180323/cbe4d534/attachment.html>

+pcc for thoughts

On Fri, Mar 23, 2018 at 9:37 AM, Bakhvalov, Denis <denis.bakhvalov at
intel.com
> wrote:
> Hello Teresa,
>
>
>
> > Without -flto, a.o ends up with a reference to __exp_finite,
>
> That’s correct.
>
>
>
> > which also would not be satifisfied out of libexp.a.
>
> That’s not correct. Even if libexp.a would have __exp_finite, it wouldn’t
> be resolved from libexp.a, because of the behavior described in my first
> message.
>
I'm asking specifically about the non-LTO case.
>
>
> > Do you also have an implementation of __exp_finite in your libexp.a?
>
> No, I don’t have __exp_finite in libexp.a. I presented complete code in my
> first message. You can reproduce it yourself on current trunk.
>
I did. I'm trying to understand how the non-LTO case is supposed to work. I
assume in your full code you must have an implementation of __exp_finite in
your libexp.a so that it is satisfied out of there and not libm.so (in the
non-LTO case). I.e. when I try the example from your message, but remove
-flto, I get the __exp_finite that is satisfied out of libm.so. I'm just
trying to verify my assumption that you are providing that as well in your
full library.

>
>
> > Can you build with -fno-builtin, or -fno-builtin-exp etc?
>
> > That results in a reference to __exp_finite in the .o bitcode
>
> > (which of course has the same issue I mentioned above, but is
> consistent).
>
> > That seems to be the option you should use here when you want to use
> your own implementations.
>
>
>
> Yes, -fno-builtin results in call to __exp_finite in the bitcode. But the
> problem I try to address is not what version of exp libcall we want to
> generate: exp or __exp_finite.
>
> The problem is that if the exp call was lowered to llvm intrinsic, linker
> doesn’t resolve it from my static library in LTO build, because plugin
> (LLVMgold.so) doesn’t report those symbols (yet in intrinsic form) to the
> linker.
>
Right, which is why I am suggesting that it might be appropriate to build
with -fno-builtin (or -fno-builtin-exp) here - this solves the LTO issue as
there will no longer be an llvm intrinsic in the bitcode. Although it is
not friendly that there is different behavior between the LTO and non-LTO
cases here.

Note that this is not specific to the gold plugin case either. With
-fuse-ld=lld:

./libexp.a: lazy definition of exp
/lib/x86_64-linux-gnu/libm.so.6: shared definition of exp
$ nm a.out | grep exp
                 U exp


Teresa

>
>
> Best regards,
> Denis Bakhvalov.
>
> ---------------------------------------------------------------------
>
> *Intel Technology Poland sp. z o.o.*ul. S
>
<https://maps.google.com/?q=ul.+S+owackiego+173+%7C+80-298+Gda+sk&entry=gmail&source=g>
> &#322owackiego 173 | 80-298 Gda
>
<https://maps.google.com/?q=ul.+S+owackiego+173+%7C+80-298+Gda+sk&entry=gmail&source=g>
> &#324sk
>
<https://maps.google.com/?q=ul.+S+owackiego+173+%7C+80-298+Gda+sk&entry=gmail&source=g>
> | S&#261d Rejonowy Gda&#324sk P&#243&#322noc | VII
Wydzia&#322 Gospodarczy
> Krajowego Rejestru S&#261dowego - KRS 101882 | NIP 957-07-52-316 |
> Kapita&#322 zak&#322adowy 200.000 PLN.
>
> Ta wiadomo&#347&#263 wraz z za&#322&#261cznikami jest
przeznaczona dla
> okre&#347lonego adresata i mo&#380e zawiera&#263 informacje
poufne. W razie
> przypadkowego otrzymania tej wiadomo&#347ci, prosimy o powiadomienie
> nadawcy oraz trwa&#322e jej usuni&#281cie; jakiekolwiek
przegl&#261danie
> lub rozpowszechnianie jest zabronione.
> This e-mail and any attachments may contain confidential material for the
> sole use of the intended recipient(s). If you are not the intended
> recipient, please contact the sender and delete all copies; any review or
> distribution by others is strictly prohibited.
>
>

-- 
Teresa Johnson |  Software Engineer |  tejohnson at google.com |  408-460-2413
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180323/c252b101/attachment.html>

> I'm trying to understand how the non-LTO case is supposed to work
non-LTO case works because when linker starts it’s job all the llvm intrinsics
are already lowered.
> Right, which is why I am suggesting that it might be appropriate to build
with -fno-builtin (or -fno-builtin-exp) here –
> this solves the LTO issue as there will no longer be an llvm intrinsic in
the bitcode
Yes, I just tested it and -fno-builtin helps in this case. I added definition of
__exp_finite to libexp.a and now it was resolved from libexp.a (because no llvm
intrinsics).

Best regards,
Denis Bakhvalov.
--------------------------------------------------------------------

Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial
Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 |
Kapital zakladowy 200.000 PLN.

Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i
moze zawierac informacje poufne. W razie przypadkowego otrzymania tej
wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie;
jakiekolwiek
przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). If you are not the intended recipient, please
contact the sender and delete all copies; any review or distribution by
others is strictly prohibited.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180326/5b6f015a/attachment.html>