New IR is an IR for Mesa intended to replace GLSL IR, and perhaps Mesa IR as well. Its design inherits from the various IR's that Mesa has used in the past, as well as Direct3D assembly, as well as a few new ideas. It is a flat (in terms of using instructions instead of expressions), typeless IR, similar to TGSI and Mesa IR. It also supports SSA (although it doesn't require it). Variables ========= New IR includes support for source-level GLSL variables through a structure mostly copied from GLSL IR. These will be used for linking and conversion from GLSL IR (and later, from an AST), but for the most part, they will be lowered to registers (see below) and loads/stores. Registers ========= Registers are light-weight; they consist of a structure that only contains its size, its index for liveness analysis, and an optional name for debugging. In addition, registers can be local to a function or global to the entire shader; the latter will be used in ARB_shader_subroutine for passing parameters and getting return values from subroutines. Registers can also be an array, in which case they can be accessed indirectly. Each ALU instruction (add, subtract, etc.) works directly with registers or SSA values (see below). SSA ======== Everywhere a register can be loaded/stored, an SSA value can be used instead. The only exception is that arrays/indirect addressing are not supported with SSA; although research has been done on extensions of SSA to arrays before, it's usually for the purpose of parallelization (which we're not interested in), and adds some overhead in the form of adding copies or extra arrays (which is much more expensive than introducing copies between non-array registers). SSA uses point directly to their corresponding definition, which in turn points to the instruction it is part of. This creates an implicit use-def chain and avoids the need for an external structure for each SSA register. Functions ========= Support for function calls is mostly similar to GLSL IR. Each shader contains a list of functions, and each function has a list of overloads. Each overload contains a list of parameters, and may contain an implementation which specifies the variables that correspond to the parameters and return value. Inlining a function, assuming it has a single return point, is as simple as copying its instructions, registers, and local variables into the target function and then inserting copies to and from the new parameters as appropriate. After functions are inlined and any non-subroutine functions are deleted, parameters and return variables will be converted to global variables and then global registers. We don't do this lowering earlier (i.e. the fortranizer idea) for a few reasons: - If we want to do optimizations before link time, we need to have the function signature available during link-time. - If a subroutine were also called as a normal function, then the inlined function would use the same global registers as the subroutine, which would hamper optimization. Although this may not be common in user code, the proprietary drivers will convert normal functions to subroutines internally so that they can then inline functions during the compile phase, reducing link time but penalizing the performance of multiple intra-stage shaders linked together (which is uncommon). We may want to do this optimization after we support subroutines, but not supporting parameters and return values in the IR will preclude it. Intrinsics ========= Any operation (other than function calls) which touches a variable or is not referentially transparent is represented by an intrinsic. Intrinsics are similar to the idea of a "builtin function," i.e. a function declaration whose implementation is provided by the backend, except they are more powerful in the following ways: - They can also load and store registers when appropriate, which limits the number of variables needed in later stages of the IR while obviating the need for a separate load/store variable instruction. - Intrinsics can be marked as side-effect free, which permits them to be treated like any other instruction when it comes to optimizations. This allows texture load instructions to be represented as intrinsics while still being optimized away by dead code elimination, common subexpression elimination, etc. Intrinsics are used for: - Texture operations - Atomic operations - Memory barriers - Subroutine calls - Geometry shader emitVertex and endPrimitive - Loading and storing variables (before lowering) - Loading and storing uniforms, shader inputs and outputs, etc (after lowering) - Copying variables (cases where in GLSL the destination is a structure or array) - The kitchen sink - ... Control Flow ========= Like in GLSL IR, control flow consists of a tree of "control flow nodes", which include if statements and loops, and jump instructions (break, continue, and return). Unlike GLSL IR, though, the leaves of the tree aren't statements but basic blocks. Each basic block also keeps track of its successors and predecessors, and function implementations keep track of the beginning basic block (the first basic block of the function) and the ending basic block (a fake basic block that every return statement points to). Together, these elements make up the control flow graph, in this case a redundant piece of information on top of the control flow tree that will be used by almost all the optimizations. There are helper functions to add and remove control flow nodes that also update the control flow graph, and so usually it doesn't need to be touched by passes that modify control flow nodes.