[llvm] [BOLT][AArch64] Implement PLTCall optimization (PR #93584)

Rafael Auler via llvm-commits llvm-commits at lists.llvm.org
Wed May 29 10:56:41 PDT 2024


================
@@ -1412,9 +1413,15 @@ class MCPlusBuilder {
     return false;
   }
 
-  /// Modify a direct call instruction \p Inst with an indirect call taking
-  /// a destination from a memory location pointed by \p TargetLocation symbol.
-  virtual bool convertCallToIndirectCall(MCInst &Inst,
+  /// Modify a direct call instruction pointed by the iterator \p It, with an
+  /// indirect call taking a destination from a memory location pointed by \p
+  /// TargetLocation symbol. If additional instructions need to be prepended
+  /// before \p It, then the iterator must be updated to point to the indirect
+  /// call instruction.
+  ///
+  /// \return true on success
+  virtual bool convertCallToIndirectCall(BinaryBasicBlock &BB,
----------------
rafaelauler wrote:

Hi Paschalis, 

Thanks a lot for submitting this contribution to the project, I appreciate it!

One thing that might not be obvious in the code base is that the MCPlusBuilder layer (or the BOLT targets lib, for that matter) do not depend on BOLT IR classes, such as BinaryBasicBlock. They are limited to use MCInst and the class MCPlusBuilder::InstructionIterator whenever the API needs to communicate a walkable MCInst pointer to target-specific code.

If you add this dependency of bolt target libs on bolt IR classes, this will create a cyclic dependency that will likely break our shared lib build (if you build BOLT with enable_shared you might see this). I would suggest you taking a look at other methods in X86MCPlusBuilder to see how we implement this kind of optimization -- usually by moving code that depends on BB knowledge to the pass itself, instead of doing that logic in target libs.

https://github.com/llvm/llvm-project/pull/93584


More information about the llvm-commits mailing list