Skip to content

Commit 3ea9ed4

Browse files
authored
[GlobalISel] Expand IRTranslator docs. NFC (llvm#89186)
Add some more details about how calls are lowered and what APIs are available.
1 parent 35159c2 commit 3ea9ed4

File tree

2 files changed

+34
-3
lines changed

2 files changed

+34
-3
lines changed

llvm/docs/GlobalISel/IRTranslator.rst

+32-3
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@ IRTranslator
66
.. contents::
77
:local:
88

9-
This pass translates the input LLVM-IR ``Function`` to a GMIR
9+
This pass translates the input LLVM-IR ``Function`` to a :doc:`GMIR`
1010
``MachineFunction``. This is typically a direct translation but does
1111
occasionally get a bit more involved. For example:
1212

@@ -51,8 +51,37 @@ Translating Function Calls
5151

5252
The ``IRTranslator`` also implements the ABI's calling convention by lowering
5353
calls, returns, and arguments to the appropriate physical register usage and
54-
instruction sequences. This is achieved using the ``CallLowering``
55-
implementation,
54+
instruction sequences. This is achieved using the ``CallLowering`` interface,
55+
which provides several hooks that targets should implement:
56+
``lowerFormalArguments``, ``lowerReturn``, ``lowerCall`` etc.
57+
58+
In essence, all of these hooks need to find a way to move the argument/return
59+
values between the virtual registers used in the rest of the function and either
60+
physical registers or the stack, as dictated by the ABI. This may involve
61+
splitting large types into smaller ones, introducing sign/zero extensions etc.
62+
In order to share as much of this code as possible between the different
63+
backends, ``CallLowering`` makes available a few helpers and interfaces:
64+
65+
* ``ArgInfo`` - used for formal arguments, but also return values, actual
66+
arguments and call results; contains info such as the IR type, the virtual
67+
registers etc; large values will likely have to be split into several
68+
``ArgInfo`` objects (``CallLowering::splitToValueTypes`` can help with that);
69+
70+
* ``ValueAssigner`` - uses a ``CCAssignFn``, usually generated by TableGen (see
71+
:ref:`backend-calling-convs`), to decide where to put each
72+
``ArgInfo`` (physical register or stack); backends can use the provided
73+
``IncomingValueAssigner`` (for formal arguments and call results) and
74+
``OutgoingValueAssigner`` (for actual arguments and function returns), but
75+
it's also possible to subclass them;
76+
77+
* ``ValueHandler`` - inserts the necessary instructions for putting each value
78+
where it belongs; it has pure virtual methods for assigning values to
79+
registers or to addresses, and a host of other helpers;
80+
81+
* ``determineAndHandleAssignments`` (or for more fine grained control,
82+
``determineAssignments`` and ``handleAssignments``) - contains some boilerplate
83+
for invoking a given ``ValueAssigner`` and ``ValueHandler`` on a series of
84+
``ArgInfo`` objects.
5685

5786
.. _irtranslator-aggregates:
5887

llvm/docs/WritingAnLLVMBackend.rst

+2
Original file line numberDiff line numberDiff line change
@@ -1503,6 +1503,8 @@ non-v9 SPARC implementations.
15031503
if (TM.getSubtarget<SparcSubtarget>().isV9())
15041504
setOperationAction(ISD::CTPOP, MVT::i32, Legal);
15051505

1506+
.. _backend-calling-convs:
1507+
15061508
Calling Conventions
15071509
-------------------
15081510

0 commit comments

Comments
 (0)