[Nouveau] [Bug 91895] [nve7] Shadow Warrior: black gun & messed up colors

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91895

--- Comment #7 from Ilia Mirkin <imirkin at alum.mit.edu> ---
OK, I think I see what's happening... the sequence goes something like this:

  3: mov u32 %r438 0x3f800000 (0)

 16: mov u32 $r0 %r445 (0)
 17: mov u32 $r1 %r452 (0)
 18: call abs BUILTIN:1 (0)
 19: mov u32 %r455 $r1 (0)
 20: nop - { $r0 $r2d } (0)
 21: nop - $p0q (0)

337: mov u32 %r1227 %r1012 (0)
338: mov u32 %r1228 %r1014 (0)
339: mov u32 %r1229 %r954 (0)
340: merge b128 %r1222q %r1227 %r1228 %r1229 %r438 (0)
341: export b128 # o[0x10] %r1222q (0)

Now the resulting "code" looks like:

  1: mov u32 $r2 0x3f800000 (8)
  7: mov u32 $r10 0x00000004 (8)

263: mov u32 $r1073741823 $r10 (8)
264: mov u32 $r0 $r11 (8)
265: mov u32 $r1 $r16 (8)
266: export b128 # o[0x10] %r1222q (8)

So it must be trying to stick this stuff into r0..r3. However there's a clobber
of $r2 between the initial move and the desire to use it, without any
constraint move being inserted. So the RA fails because it doesn't understand
the situation properly. I *think*.

Not sure why the first 3 args of the merge have a mov but the 4th one doesn't.
Perhaps something eliminates it for some reason? Also worth noting that this
works fine on GK110, presumably due to slightly different RA constraints.
However we don't get anywhere close to using up the 64 registers here either.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/nouveau/attachments/20150906/d8e31505/attachment.html>