<div dir="ltr">ping </div> <div class="gmail_quote"><div dir="ltr">On Mon, Oct 29, 2018 at 12:14 PM Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This has thrown a few people off recently and it's good to have the process and all the rational for it documented somewhere. A comment at the top of nir_inline_functions seems as good a place as any. Cc: Matt Turner <<a href="mailto:mattst88@gmail.com" target="_blank">mattst88@gmail.com</a>> Cc: Karol Herbst <<a href="mailto:kherbst@redhat.com" target="_blank">kherbst@redhat.com</a>> --- src/compiler/nir/nir_inline_functions.c | 68 +++++++++++++++++++++++++ 1 file changed, 68 insertions(+) diff --git a/src/compiler/nir/nir_inline_functions.c b/src/compiler/nir/nir_inline_functions.c index 06c90d93956..29474bb417b 100644 --- a/src/compiler/nir/nir_inline_functions.c +++ b/src/compiler/nir/nir_inline_functions.c @@ -132,6 +132,74 @@ inline_function_impl(nir_function_impl *impl, struct set *inlined) return progress; } +/** A pass to inline all functions in a shader into their callers + * + * For most use-cases, function inlining is a multi-step process. The general + * pattern employed by SPIR-V consumers and others is as follows: + * + * 1. nir_lower_constant_initializers(shader, nir_var_local) + * + * This is needed because local variables from the callee are simply added + * to the locals list for the caller and the information about where the + * constant initializer logically happens is lost. If the callee is + * called in a loop, this can cause the variable to go from being + * initialized once per loop iteration to being initialized once at the + * top of the caller and values to persist from one invocation of the + * callee to the next. The simple solution to this problem is to get rid + * of constant initializers before function inlining. + * + * 2. nir_lower_returns(shader) + * + * nir_inline_functions assumes that all functions end "naturally" by + * execution reaching the end of the function without any return + * instructions causing instant jumps to the end. Thanks to NIR being + * structured, we can't represent arbitrary jumps to various points in the + * program which is what an early return in the callee would have to turn + * into when we inline it into the caller. Instead, we require returns to + * be lowered which lets us just copy+paste the callee directly into the + * caller. + * + * 3. nir_inline_functions(shader) + * + * This does the actual function inlining and the resulting shader will + * contain no call instructions. + * + * 4. nir_copy_prop(shader) + * + * Most functions contain pointer parameters where the result of a deref + * instruction is passed in as a parameter, loaded via a load_param + * intrinsic, and then turned back into a deref via a cast. Running copy + * propagation gets rid of the intermediate steps and results in a whole + * deref chain again. This is currently required by a number of + * optimizations and lowering passes at least for certain variable modes. + * + * 5. Loop over the functions and delete all but the main entrypoint. + * + * In the Intel Vulkan driver this looks like this: + * + * foreach_list_typed_safe(nir_function, func, node, &nir->functions) { + * if (func != entry_point) + * exec_node_remove(&func->node); + * } + * assert(exec_list_length(&nir->functions) == 1); + * + * While nir_inline_functions does get rid of all call instructions, it + * doesn't get rid of any functions because it doesn't know what the "root + * function" is. Instead, it's up to the individual driver to know how to + * decide on a root function and delete the rest. With SPIR-V, + * spirv_to_nir returns the root function and so we can just use == whereas + * with GL, you may have to look for a function named "main". + * + * 6. nir_lower_constant_initializers(shader, ~nir_var_local) + * + * Lowering constant initializers on inputs, outputs, global variables, + * etc. requires that we know the main entrypoint so that we know where to + * initialize them. Otherwise, we would have to assume that anything + * could be a main entrypoint and initialize them at the start of every + * function but that would clearly be wrong if any of those functions were + * ever called within another function. Simply requiring a single- + * entrypoint function shader is the best way to make it well-defined. + */ bool nir_inline_functions(nir_shader *shader) { -- 2.19.1 </blockquote></div>