diff options
| -rw-r--r-- | src/compiler/nir/docs/control_flow.rst | 6 | ||||
| -rw-r--r-- | src/compiler/nir/docs/instructions.rst | 10 | ||||
| -rw-r--r-- | src/compiler/nir/docs/intro.rst | 4 | ||||
| -rw-r--r-- | src/compiler/nir/docs/variables.rst | 8 |
4 files changed, 14 insertions, 14 deletions
diff --git a/src/compiler/nir/docs/control_flow.rst b/src/compiler/nir/docs/control_flow.rst index e10e30bf57..8dff834dd3 100644 --- a/src/compiler/nir/docs/control_flow.rst +++ b/src/compiler/nir/docs/control_flow.rst @@ -107,7 +107,7 @@ guarantee. Therefore, optimizations in any intermediate IR must respect this invariant, which means that the IR must have a good idea of when control flow diverges. For example, in the following snippet: -:: +.. code-block:: c vec2 color = texture(tex, coordinate * 2.0) if (foo) { @@ -142,7 +142,7 @@ Together, the start block, end block, and graph created by the successors and predecessors form the control flow graph that complements the control flow tree. For example, this: -:: +.. code-block:: c void main(void) { if (foo) @@ -273,7 +273,7 @@ be moved. On the basic block level, creating the empty block removes a *critical edge*, which is an edge from a block with more than one successor to another with more than one predecessor. Consider this if-then statement: -:: +.. code-block:: c if (foo) { bar = 1; diff --git a/src/compiler/nir/docs/instructions.rst b/src/compiler/nir/docs/instructions.rst index f016e8d2c3..0fb39a0a9a 100644 --- a/src/compiler/nir/docs/instructions.rst +++ b/src/compiler/nir/docs/instructions.rst @@ -65,7 +65,7 @@ opcodes are created using the ``opcode`` function, which constructs the object and adds it to the list, as well as various helper functions which call ``opcode``. For example, the following line in nir_opcodes.py: -:: +.. code-block:: c binop("fmul", tfloat, commutative + associative, "src0 * src1") @@ -73,7 +73,7 @@ creates a declaration of a nir_op_fmul member of the ``nir_op`` enum, which is defined in the generated file nir_opcodes.h, as well as the following entry in the nir_op_infos array (defined in nir_opcodes.c): -:: +.. code-block:: c { .name = "fmul", @@ -100,7 +100,7 @@ implemented for you, and all you have to do is write the ``some_func``. In this case, the definition of ``fmul`` also creates the following code in nir_constant_expressions.c: -:: +.. code-block:: c static nir_const_value evaluate_fmul(unsigned num_components, nir_const_value *_src) @@ -122,7 +122,7 @@ nir_constant_expressions.c: as well as the following case in ``nir_eval_const_opcode``: -:: +.. code-block:: c case nir_op_fmul: { return evaluate_fmul(num_components, src); @@ -183,7 +183,7 @@ macros. nir_intrinsics.h is included twice, once in nir.h to create the ``nir_intrinsic_infos`` array. For example, here's the definition of the ``store_var`` intrinsic: -:: +.. code-block:: c INTRINSIC(store_var, 1, ARR(0), false, 0, 1, 0, 0) diff --git a/src/compiler/nir/docs/intro.rst b/src/compiler/nir/docs/intro.rst index 7e91fa2db3..c7dfdd7d83 100644 --- a/src/compiler/nir/docs/intro.rst +++ b/src/compiler/nir/docs/intro.rst @@ -43,7 +43,7 @@ Organization NIR is written in C, although in a very object-oriented manner. Structures and enums are typedef'ed: -:: +.. code-block:: c typedef struct nir_foo { /* stuff */ @@ -60,7 +60,7 @@ through inline functions defined by the NIR_DEFINE_CAST macro. For example, here's how an animal structure inherited by cows, cats, and dogs would be defined: -:: +.. code-block:: c typedef enum { nir_animal_type_cow, diff --git a/src/compiler/nir/docs/variables.rst b/src/compiler/nir/docs/variables.rst index 12ddd1ed45..5567ebda39 100644 --- a/src/compiler/nir/docs/variables.rst +++ b/src/compiler/nir/docs/variables.rst @@ -25,7 +25,7 @@ supports so-called "wildcard" array dereferences, which are used for array copies (the ``copy_var`` intrinsic). For example, this allows us to support something like: -:: +.. code-block:: c struct s { vec4 a, b; @@ -33,7 +33,7 @@ something like: struct s foo[10], bar[10]; //... - foo[*].a = bar[*].a + foo[*].a = bar[*].a; where we can copy part of each element of the array. This is useful because it helps make converting part of the variable into SSA easier. For example, if it @@ -42,13 +42,13 @@ turns out that ``foo[*].a`` (i.e. all the elements ``foo[0].a``, ``foo[1].a``, sometimes accessed indirectly, we can convert ``foo[*].a`` to SSA values while only keeping around ``foo[*].b``. Therefore, we lower array copies like -:: +.. code-block:: c foo = bar; to multiple wildcard copies like -:: +.. code-block:: c foo[*].a = bar[*].a; foo[*].b = bar[*].b; |