[PATCH] D81126: [PowerPC] Fix for PC Relative call protocol

Victor Huang via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jun 12 11:26:22 PDT 2020


NeHuang added a comment.
Herald added a subscriber: wuzish.

nit: In the SUMMARY section `cnop` -> `nop`



================
Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:4678
   // single TOC. Since each module will be addressed with a single TOC then we
   // only need to check that caller and callee don't cross dso boundaries.
   if (CodeModel::Medium == TM.getCodeModel() ||
----------------
nit: I think we should update the comment here as we are checking new scenarios below. 


================
Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:4696
+    if (!STICaller->isUsingPCRelativeCalls() &&
+        STICallee->isUsingPCRelativeCalls())
+      return false;
----------------
The fix makes sense to me.  

For the other two scenarios:
1. Caller using PCRelative addressing, callee using TOC.
2. Caller using PCRelative addressing, callee using PCRelative addressing.

In both cases, is it possible TOC could be clobbered in the caller (same as the test case below when it call external function externalFunc)?  Can we say caller and callee are not sharing the same TOC base?
If so, caller and callee are not share the same TOC but we do not need nop to restore the TOC in the caller. 

In this sense, shall we rename this function to `callDoesNotRequireTOCRestore` since the previous assumption no longer hold for PCRelative addressing?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D81126/new/

https://reviews.llvm.org/D81126





More information about the llvm-commits mailing list