[Nouveau] [Bug 90887] PhiMovesPass in register allocator broken

[bugzilla-daemon at freedesktop.org]

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

--- Comment #8 from jr <j-r at online.de> ---
Note that I really do have no clue of the whole system and only a very rough
understanding of SSA, but I think your result is the same as mine. The targets
of the newly inserted mov instructions are fine, because the PhiMoves pass
inserts them corresponding to mthe new phi sources, but the sources are
reversed, because the edges have been reordered (ironically by the PhiMoves
pass itself).

An edge newly attached using attach will always be the first in iteration
order. Therefore the problem happens as follows: when - as is the case here -
the second edge fulfills the needsNewElseBlock() condition it will be split to
insert the new BB for the copies. The old code accomplishes this using detach()
and attach() resulting in the new BB being attached - BB17 here - by the first
incoming edge and the previous first incoming edge - from BB10 in this case -
is now the second, but without a corresponding reorder of the phi node sources.

AFAICT the problem is that attach() or detach() don't preserve the incoming
edge/phi source correspondence. They shouldn't be used during SSA.

-- 
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/20150617/50098ab9/attachment.html>