i965/nir: do int64 lowering before optimization
authorIago Toral Quiroga <itoral@igalia.com>
Fri, 1 Dec 2017 12:46:23 +0000 (13:46 +0100)
committerIago Toral Quiroga <itoral@igalia.com>
Tue, 6 Feb 2018 06:49:27 +0000 (07:49 +0100)
commit1d20001d9711a7ea06f42292d3ed545d7ca0f50c
treeb1ac5c33ce199a5695601cb27c5f887992bae87c
parent02a6d901eee188492af54e98c92680a607b02bf8
i965/nir: do int64 lowering before optimization

Otherwise loop unrolling will fail to see the actual cost of
the unrolling operations when the loop body contains 64-bit integer
instructions, and very specially when the divmod64 lowering applies,
since its lowering is quite expensive.

Without this change, some in-development CTS tests for int64
get stuck forever trying to register allocate a shader with
over 50K SSA values. The large number of SSA values is the result
of NIR first unrolling multiple seemingly simple loops that involve
int64 instructions, only to then lower these instructions to produce
a massive pile of code (due to the divmod64 lowering in the unrolled
instructions).

With this change, loop unrolling will see the loops with the int64
code already lowered and will realize that it is too expensive to
unroll.

v2: Run nir_algebraic first so we can hopefully get rid of some of
    the int64 instructions before we even attempt to lower them.

Reviewed-by: Matt Turner <mattst88@gmail.com>
src/intel/compiler/brw_nir.c