<html><body><p><font size="2">Hi Lang,</font><br><br><font size="2">yes, if the target function resides in a different module, we must go via the target's global entry point (which actually implies constructing and using a stub, since the GEP requires r12 to be set up, which only the stub will do), and we must also insert the load instruction to reload the prior TOC after the function has returned.</font><br><br><font size="2">The current code in RuntimeDyldELF::processRelocationRef uses this test:</font><br><br><font size="2"> // A PPC branch relocation will need a stub function if the target is</font><br><font size="2"> // an external symbol (either Value.SymbolName is set, or SymType is</font><br><font size="2"> // Symbol::ST_Unknown) or if the target address is not within the</font><br><font size="2"> // signed 24-bits branch address.</font><br><br><font size="2">and later:</font><br><br><font size="2"> if (Value.SymbolName || SymType == SymbolRef::ST_Unknown) {</font><br><font size="2"> // Restore the TOC for external calls<br></font><br><font size="2">From the discussion it appears that this condition (SymbolName set or SymbolType is unknown) is not sufficient, and there are other cases where the target routine may be in a different module. In that case, the correct fix would be to update those checks to make the condition precise.</font><br><br><font size="2">I do not think we can simply unconditionally use a stub for *every* function call -- not only would this be a significant performance overhead, it may not even be possible: in order to insert code to restore the TOC, there has to be a nop placeholder in the appropriate spot (after the call), and the compiler does not even put the nop there if it knowns for sure that the target is in the same module.</font><br><br><font size="2"><br>Mit freundlichen Gruessen / Best Regards<br><br>Ulrich Weigand<br><br>-- <br> Dr. Ulrich Weigand | Phone: +49-7031/16-3727<br> STSM, GNU/Linux compilers and toolchain<br> IBM Deutschland Research & Development GmbH<br> Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk Wittkopp<br> Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294</font><br><br><img width="16" height="16" src="cid:1__=4EBB08F5DFA316728f9e8a93df938690918c4EB@" border="0" alt="Inactive hide details for Lang Hames ---05.04.2018 00:39:00---Hi Ulrich, and any other llvm PowerPC/JIT users, It looks like th"><font size="2" color="#424282">Lang Hames ---05.04.2018 00:39:00---Hi Ulrich, and any other llvm PowerPC/JIT users, It looks like the Numba maintainers have run in to</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Lang Hames <lhames@gmail.com></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">Ulrich Weigand <ulrich.weigand@de.ibm.com>, LLVM Developers Mailing List <llvm-dev@lists.llvm.org></font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">05.04.2018 00:39</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">LLVM PPC JIT Error</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br>Hi Ulrich, and any other llvm PowerPC/JIT users,<br><br>It looks like the Numba maintainers have run in to an issue with RuntimeDyldELF's PowerPC support (See <a href="https://github.com/numba/numba/issues/2451#issuecomment-377739948"><u><font color="#0000FF">https://github.com/numba/numba/issues/2451#issuecomment-377739948</font></u></a> and later comments)<br><br>Due to a recent change to weak symbol handling, we now always resolve to the first copy of a function that is emitted (discarding redundant weak/odr definitions in the subsequent objects). It seems that this is resulting in PPC functions referring to the wrong TOC.<br><br>I think one valid solution would be to always use to the global function entry point and update the TOC pointer, but I don't have a good sense of how much overhead this would impose, or how performance sensitive current powerpc clients are.<br><br>Otherwise I think we should track which functions came from which object and pick the global entry point where appropriate.<br><br>Do you have any thoughts on this? Or any suggestions on the best person to speak to about ELF/PowerPC JIT support?<br><br>Cheers,<br>Lang.<br><br><BR>
</body></html>