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.