From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ@public.gmane.org Subject: [Bug 90887] PhiMovesPass in register allocator broken Date: Wed, 17 Jun 2015 18:59:38 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0139523473==" Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nouveau-bounces-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org Sender: "Nouveau" To: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org List-Id: nouveau.vger.kernel.org --===============0139523473== Content-Type: multipart/alternative; boundary="1434567578.52207C0.18119"; charset="UTF-8" --1434567578.52207C0.18119 Date: Wed, 17 Jun 2015 18:59:38 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" https://bugs.freedesktop.org/show_bug.cgi?id=90887 --- Comment #8 from jr --- 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. --1434567578.52207C0.18119 Date: Wed, 17 Jun 2015 18:59:38 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8"

Comment # 8 on bug 90887 from 
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.
--1434567578.52207C0.18119-- --===============0139523473== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTm91dmVhdSBt YWlsaW5nIGxpc3QKTm91dmVhdUBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cDovL2xpc3RzLmZy ZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25vdXZlYXUK --===============0139523473==--