summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorDylan Baker <dylan@pnwbakers.com>2016-12-19 11:30:39 -0800
committerDylan Baker <dylan@pnwbakers.com>2016-12-19 11:32:39 -0800
commitace3db9dcedfc046928ec69029a6389ef94d16ec (patch)
treeb3ee28c739828dbc359a5a55a756c347b774166f
parentd44aae66cbf000bdca596b4476f17b4218e41151 (diff)
nir/docs: use syntax highlighted code blocks
-rw-r--r--src/compiler/nir/docs/control_flow.rst6
-rw-r--r--src/compiler/nir/docs/instructions.rst10
-rw-r--r--src/compiler/nir/docs/intro.rst4
-rw-r--r--src/compiler/nir/docs/variables.rst8
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;