nvc0/ir: propagate immediates to CALL input MOVs
authorTobias Klausmann <tobias.johannes.klausmann@mni.thm.de>
Sun, 13 Aug 2017 01:02:39 +0000 (03:02 +0200)
committerIlia Mirkin <imirkin@alum.mit.edu>
Fri, 1 Sep 2017 02:58:06 +0000 (22:58 -0400)
commit1c4e6d7ca83578caf5212f7a484538cb1b4ae2a3
tree6d0cf9c9ccd3f5559691c25cd2a6c5ab356793d5
parentb672c3833b7ea51c09a6bcbed86b8fb6789448f1
nvc0/ir: propagate immediates to CALL input MOVs

On using builtin functions we have to move the input to registers $0 and $1, if
one of the input value is an immediate, we fail to propagate the immediate:

...
mov u32 $r477 0x00000003 (0)
...
mov u32 $r0 %r473 (0)
mov u32 $r1 $r477 (0)
call abs BUILTIN:0 (0)
mov u32 %r495 $r1 (0)
...

With this patch the immediate is propagated, potentially causing the first MOV
to be superfluous, which we'd remove in that case:

...

mov u32 $r0 %r473 (0)
mov u32 $r1 0x00000003 (0)
call abs BUILTIN:0 (0)
mov u32 %r495 $r1 (0)
...

Shaderdb stats:
total instructions in shared programs : 4893460 -> 4893324 (-0.00%)
total gprs used in shared programs    : 582972 -> 582881 (-0.02%)
total local used in shared programs   : 17960 -> 17960 (0.00%)

                local        gpr       inst      bytes
    helped           0          91         112         112
      hurt           0           0           0           0

v2:
 implement some changes proposed by imirkin, the manual deletion of the dead
 mov is necessary after ea22ac23e0 ("nvc0/ir: unlink values pre- and post-call
 to division function") as the potentially dead mov is unlinked properly,
 causing later passes to not notice the mov op at all and thus not cleaning it
 up. That makes up a big chunk of the regression the above commit caused.
 Keep the deletion of the op where it is, deleting it later unnecessarily blows
 up size of the change.

Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp