[GlobalISel] Expand IRTranslator docs. NFC (#89186)
Add some more details about how calls are lowered and what APIs are available.
This commit is contained in:
parent
35159c2e81
commit
3ea9ed471c
@ -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:
|
||||
|
||||
|
@ -1503,6 +1503,8 @@ non-v9 SPARC implementations.
|
||||
if (TM.getSubtarget<SparcSubtarget>().isV9())
|
||||
setOperationAction(ISD::CTPOP, MVT::i32, Legal);
|
||||
|
||||
.. _backend-calling-convs:
|
||||
|
||||
Calling Conventions
|
||||
-------------------
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user