[Mesa-dev] [PATCH 4/4] gallivm: dump bitcode before optimization
Jose Fonseca
jfonseca at vmware.com
Mon Apr 23 11:57:19 UTC 2018
On 23/04/18 05:24, sroland at vmware.com wrote:
> From: Roland Scheidegger <sroland at vmware.com>
>
> If we dump the bitcode for off-line debug purposes, we really want the
> pre-optimized bitcode, otherwise it's useless in identifying problems
> with IR optimization (if you have a shader which takes an hour to do
> IR optimization, it's also nice you don't have to wait that hour...).
> Also, print out the function passes for opt which correspond to what
> was used for jit compilation (and also the opt level for codegen).
> Using opt/llc this way should then pretty much mimic what was done
> for jit. (When specifying something like -time-passes
> -debug-pass=[Structure|Arguments] (for either opt or llc) that also
> gives very useful information in which passes all the time was spent,
> and which passes are really run along with the order - llvm will add
> passes due to dependencies on its own, and of course -O2 for llc
> comes with a ~100 pass list.)
> ---
> src/gallium/auxiliary/gallivm/lp_bld_init.c | 35 +++++++++++++++++------------
> 1 file changed, 21 insertions(+), 14 deletions(-)
>
> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_init.c b/src/gallium/auxiliary/gallivm/lp_bld_init.c
> index d0afff1..41d828c 100644
> --- a/src/gallium/auxiliary/gallivm/lp_bld_init.c
> +++ b/src/gallium/auxiliary/gallivm/lp_bld_init.c
> @@ -142,6 +142,10 @@ create_pass_manager(struct gallivm_state *gallivm)
> * TODO: Evaluate passes some more - keeping in mind
> * both quality of generated code and compile times.
> */
> + /*
> + * NOTE: if you change this, don't forget to change the output
> + * with GALLIVM_DEBUG_DUMP_BC in gallivm_compile_module.
> + */
> LLVMAddScalarReplAggregatesPass(gallivm->passmgr);
> LLVMAddEarlyCSEPass(gallivm->passmgr);
> LLVMAddCFGSimplificationPass(gallivm->passmgr);
> @@ -151,7 +155,7 @@ create_pass_manager(struct gallivm_state *gallivm)
> * due to licm implying lcssa (since llvm 3.5), which can take forever.
> * Even for sane shaders, the cost of licm is rather high (and not just
> * due to lcssa, licm itself too), though mostly only in cases when it
> - * can actually move things, so having to disable it is a pity.
> + * can actually move things, so having to disable it is a pity.
> * LLVMAddLICMPass(gallivm->passmgr);
> */
> LLVMAddReassociatePass(gallivm->passmgr);
> @@ -597,6 +601,22 @@ gallivm_compile_module(struct gallivm_state *gallivm)
> gallivm->builder = NULL;
> }
>
> + /* Dump bitcode to a file */
> + if (gallivm_debug & GALLIVM_DEBUG_DUMP_BC) {
> + char filename[256];
> + assert(gallivm->module_name);
> + util_snprintf(filename, sizeof(filename), "ir_%s.bc", gallivm->module_name);
> + LLVMWriteBitcodeToFile(gallivm->module, filename);
> + debug_printf("%s written\n", filename);
> + debug_printf("Invoke as \"opt %s %s | llc -O%d %s%s\"\n",
> + gallivm_debug & GALLIVM_DEBUG_NO_OPT ? "-mem2reg" :
> + "-sroa -early-cse -simplifycfg -reassociate "
> + "-mem2reg -constprop -instcombine -gvn",
> + filename, gallivm_debug & GALLIVM_DEBUG_NO_OPT ? 0 : 2,
> + (HAVE_LLVM >= 0x0305) ? "[-mcpu=<-mcpu option>] " : "",
> + "[-mattr=<-mattr option(s)>]");
> + }
> +
> if (gallivm_debug & GALLIVM_DEBUG_PERF)
> time_begin = os_time_get();
>
> @@ -630,19 +650,6 @@ gallivm_compile_module(struct gallivm_state *gallivm)
> gallivm->module_name, time_msec);
> }
>
> - /* Dump byte code to a file */
> - if (gallivm_debug & GALLIVM_DEBUG_DUMP_BC) {
> - char filename[256];
> - assert(gallivm->module_name);
> - util_snprintf(filename, sizeof(filename), "ir_%s.bc", gallivm->module_name);
> - LLVMWriteBitcodeToFile(gallivm->module, filename);
> - debug_printf("%s written\n", filename);
> - debug_printf("Invoke as \"llc %s%s -o - %s\"\n",
> - (HAVE_LLVM >= 0x0305) ? "[-mcpu=<-mcpu option>] " : "",
> - "[-mattr=<-mattr option(s)>]",
> - filename);
> - }
> -
> if (use_mcjit) {
> /* Setting the module's DataLayout to an empty string will cause the
> * ExecutionEngine to copy to the DataLayout string from its target
>
Series looks good to me.
Reviewed-by: Jose Fonseca <jfonseca at vmware.com>
More information about the mesa-dev
mailing list