diff --git a/llvm/docs/GlobalISel/IRTranslator.rst b/llvm/docs/GlobalISel/IRTranslator.rst index 6268ebb4f4a1d..0cb596c516e2f 100644 --- a/llvm/docs/GlobalISel/IRTranslator.rst +++ b/llvm/docs/GlobalISel/IRTranslator.rst @@ -6,7 +6,7 @@ IRTranslator .. contents:: :local: -This pass translates the input LLVM-IR ``Function`` to a GMIR +This pass translates the input LLVM-IR ``Function`` to a :doc:`GMIR` ``MachineFunction``. This is typically a direct translation but does occasionally get a bit more involved. For example: @@ -51,8 +51,37 @@ Translating Function Calls The ``IRTranslator`` also implements the ABI's calling convention by lowering calls, returns, and arguments to the appropriate physical register usage and -instruction sequences. This is achieved using the ``CallLowering`` -implementation, +instruction sequences. This is achieved using the ``CallLowering`` interface, +which provides several hooks that targets should implement: +``lowerFormalArguments``, ``lowerReturn``, ``lowerCall`` etc. + +In essence, all of these hooks need to find a way to move the argument/return +values between the virtual registers used in the rest of the function and either +physical registers or the stack, as dictated by the ABI. This may involve +splitting large types into smaller ones, introducing sign/zero extensions etc. +In order to share as much of this code as possible between the different +backends, ``CallLowering`` makes available a few helpers and interfaces: + +* ``ArgInfo`` - used for formal arguments, but also return values, actual + arguments and call results; contains info such as the IR type, the virtual + registers etc; large values will likely have to be split into several + ``ArgInfo`` objects (``CallLowering::splitToValueTypes`` can help with that); + +* ``ValueAssigner`` - uses a ``CCAssignFn``, usually generated by TableGen (see + :ref:`backend-calling-convs`), to decide where to put each + ``ArgInfo`` (physical register or stack); backends can use the provided + ``IncomingValueAssigner`` (for formal arguments and call results) and + ``OutgoingValueAssigner`` (for actual arguments and function returns), but + it's also possible to subclass them; + +* ``ValueHandler`` - inserts the necessary instructions for putting each value + where it belongs; it has pure virtual methods for assigning values to + registers or to addresses, and a host of other helpers; + +* ``determineAndHandleAssignments`` (or for more fine grained control, + ``determineAssignments`` and ``handleAssignments``) - contains some boilerplate + for invoking a given ``ValueAssigner`` and ``ValueHandler`` on a series of + ``ArgInfo`` objects. .. _irtranslator-aggregates: diff --git a/llvm/docs/WritingAnLLVMBackend.rst b/llvm/docs/WritingAnLLVMBackend.rst index 31ebc6204c98f..f1f07e4681d50 100644 --- a/llvm/docs/WritingAnLLVMBackend.rst +++ b/llvm/docs/WritingAnLLVMBackend.rst @@ -1503,6 +1503,8 @@ non-v9 SPARC implementations. if (TM.getSubtarget().isV9()) setOperationAction(ISD::CTPOP, MVT::i32, Legal); +.. _backend-calling-convs: + Calling Conventions -------------------