<div dir="ltr">+pcc for thoughts<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 23, 2018 at 9:37 AM, Bakhvalov, Denis <span dir="ltr"><<a href="mailto:denis.bakhvalov@intel.com" target="_blank">denis.bakhvalov@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="PL">
<div class="gmail-m_-5953485518482386796WordSection1">
<p class="MsoNormal"><a name="m_-5953485518482386796__MailEndCompose"><span lang="EN-US">Hello Teresa,<u></u><u></u></span></a></p><span class="gmail-">
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">> Without -flto, a.o ends up with a reference to __exp_finite,<u></u><u></u></span></p>
</span><p class="MsoNormal"><span lang="EN-US">That’s correct.<u></u><u></u></span></p><span class="gmail-">
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">> which also would not be satifisfied out of libexp.a.
<u></u><u></u></span></p>
</span><p class="MsoNormal"><span lang="EN-US">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.</span></p></div></div></blockquote><div><br></div><div>I'm asking specifically about the non-LTO case.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="PL"><div class="gmail-m_-5953485518482386796WordSection1"><p class="MsoNormal"><span lang="EN-US"><u></u><u></u></span></p><span class="gmail-">
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">> Do you also have an implementation of __exp_finite in your libexp.a?<u></u><u></u></span></p>
</span><p class="MsoNormal"><span lang="EN-US">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.</span></p></div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="PL"><div class="gmail-m_-5953485518482386796WordSection1"><p class="MsoNormal"><span lang="EN-US"><u></u><u></u></span></p><span class="gmail-">
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">> Can you build with -fno-builtin, or -fno-builtin-exp etc?
<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">> That results in a reference to __exp_finite in the .o bitcode
<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">> (which of course has the same issue I mentioned above, but is consistent).
<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">> That seems to be the option you should use here when you want to use your own implementations.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
</span><p class="MsoNormal"><span lang="EN-US">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">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.</span></p></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>Note that this is not specific to the gold plugin case either. With -fuse-ld=lld:</div><div><br></div><div>./libexp.a: lazy definition of exp</div><div>/lib/x86_64-linux-gnu/libm.so.6: shared definition of exp</div><div>$ nm a.out | grep exp</div><div>                 U exp</div><div><br></div><div><br></div><div>Teresa</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="PL"><div class="gmail-m_-5953485518482386796WordSection1"><p class="MsoNormal"><span lang="EN-US"> <u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Best regards,<br>
Denis Bakhvalov.</span><span lang="EN-US" style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></p>
</div><span class="gmail-">
<p>------------------------------<wbr>------------------------------<wbr>---------<br>
<strong style="line-height:11.25pt"><span style="font-size:9pt;color:rgb(89,89,89)"><span style="font-family:"Arial Narrow",sans-serif">Intel
Technology Poland sp. z o.o.<br></span></span></strong><span style="color:rgb(89,89,89);font-family:"Arial Narrow",sans-serif;font-size:9pt;line-height:11.25pt"><a href="https://maps.google.com/?q=ul.+S+owackiego+173+%7C+80-298+Gda+sk&entry=gmail&source=g">ul. S</a>&#322<a href="https://maps.google.com/?q=ul.+S+owackiego+173+%7C+80-298+Gda+sk&entry=gmail&source=g">owackiego 173 | 80-298 Gda</a>&#324<a href="https://maps.google.com/?q=ul.+S+owackiego+173+%7C+80-298+Gda+sk&entry=gmail&source=g">sk</a> | 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.</span></p><p>

<span>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.<br>
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.</span></p><p class="MsoNormal"><u></u><u></u></p>
</span></div>

</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><span style="font-family:Times;font-size:medium"><table cellspacing="0" cellpadding="0"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small"><td nowrap style="border-top:2px solid rgb(213,15,37)">Teresa Johnson |</td><td nowrap style="border-top:2px solid rgb(51,105,232)"> Software Engineer |</td><td nowrap style="border-top:2px solid rgb(0,153,57)"> <a href="mailto:tejohnson@google.com" target="_blank">tejohnson@google.com</a> |</td><td nowrap style="border-top:2px solid rgb(238,178,17)"> 408-460-2413</td></tr></tbody></table></span></div>
</div></div>