[RFC] Relax Language Specification

rfcs/assets/0106/spec.md

@@ -276,12 +276,13 @@ To simplify the writing of Relax passes, we define a normal form for Relax progr
 
 The normal form for Relax is very similar to ANF; differences will be noted. Here are the criteria required for a program to be in normal form:
 1. Within a `SeqExpr`, the right-hand side of any binding (the `value` field in the AST) must either be a "leaf expression" or a non-leaf expression where all subexpressions are leaf expressions. Leaf expressions are the following: Variables (`Var`, `DataflowVar`, or `GlobalVar`), `Constant`, `ShapeExpr`, `PrimValue`, `StringImm`, `DataTypeImm`, or (_unlike_ ANF) `Tuple`. `Tuple` nodes are considered "leaf" expressions even though they contain nesting purely for convenience in writing passes; many operators rely on grouping arguments using tuples, so that is a form of nesting permitted and expected. Otherwise, non-leaf expressions used as subexpressions must be bound to variables; this includes any non-leaf expressions nested inside a `Tuple`.
-2. `SeqExpr`s may appear only in the following locations:
+2. As an addition to the above, all variables of type `TupleStructInfo([])`, the unit tuple, are inlined during normalization. That is, all uses of variables with the type `TupleStructInfo([])` will be replaced directly with the value `Tuple([])` (the unit tuple).
+3. `SeqExpr`s may appear only in the following locations:
     1. In the `body` field of a `Function` node.
     2. In the `true_branch` and `false_branch` fields of `If` nodes.
-3. In fact, the `body` field of a `Function` node and the `true_branch` and `false_branch` fields of `If` nodes _must_ be `SeqExpr`s. If these fields are not `SeqExpr`s, they must be "wrapped" in a `SeqExpr`.
-4. Within a `SeqExpr`, `BindingBlock`s must be consolidated. For example, if there is a `BindingBlock` that comes after another `BindingBlock`, the two blocks should be combined to form a single `BindingBlock` with all the bindings in the same order. Consecutive `DataflowBlock`s should be consolidated as well. Empty `BindingBlock`s should be dropped. However, a `DataflowBlock` cannot be consolidated with an ordinary `BindingBlock`. If all the `BindingBlock`s are empty, then the `blocks` field of the `SeqExpr` should be set to an empty list.
-5. Calls to `Op` nodes can have custom normalization rules in order to ensure that calls to those operators will conform to certain specific rules (ideally, these should be _more_ and not _less_ restrictive than the other rules of normal form). In particular, `call_tir` and related operators include a custom normalization rule that requires the arguments to the `PrimFunc` to be provided as a tuple _literal_, rather than, say, a variable that evaluates to a tuple.
+4. In fact, the `body` field of a `Function` node and the `true_branch` and `false_branch` fields of `If` nodes _must_ be `SeqExpr`s. If these fields are not `SeqExpr`s, they must be "wrapped" in a `SeqExpr`.
+5. Within a `SeqExpr`, `BindingBlock`s must be consolidated. For example, if there is a `BindingBlock` that comes after another `BindingBlock`, the two blocks should be combined to form a single `BindingBlock` with all the bindings in the same order. Consecutive `DataflowBlock`s should be consolidated as well. Empty `BindingBlock`s should be dropped. However, a `DataflowBlock` cannot be consolidated with an ordinary `BindingBlock`. If all the `BindingBlock`s are empty, then the `blocks` field of the `SeqExpr` should be set to an empty list.
+6. Calls to `Op` nodes can have custom normalization rules in order to ensure that calls to those operators will conform to certain specific rules (ideally, these should be _more_ and not _less_ restrictive than the other rules of normal form). In particular, `call_tir` and related operators include a custom normalization rule that requires the arguments to the `PrimFunc` to be provided as a tuple _literal_, rather than, say, a variable that evaluates to a tuple.
 
 Programs that are parsed should be "normalized" before performing `StructInfo` checking or before doing any further optimizations. Note that the process of "flattening" `SeqExpr`s and consolidating `BindingBlock`s does increase the visibility of the variables in those `SeqExpr`s and `BindingBlock`s, but this is safe, since it will not cause any variable to be referenced outside of its original scope. The specification does not require any particular method of normalizing a program so long as the final program conforms to the above-listed criteria. Here is a general approach:
 1. For each function in the `IRModule`, ensure that the body is a `SeqExpr`. If the body is not a `SeqExpr`, wrap the function body in a `SeqExpr`, creating a new `BindingBlock` to hold `VarBinding`s for any non-leaf expressions that need to be bound to variables.