https://bugs.freedesktop.org/show_bug.cgi?id=91895
--- Comment #7 from Ilia Mirkin <[email protected]> --- 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.
_______________________________________________ Nouveau mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/nouveau
