On 03/02/15 01:38, Richard Biener wrote:
On Mon, Mar 2, 2015 at 6:34 AM, Aldy Hernandez <al...@redhat.com> wrote:
As I mention in the PR...
What's happening here is that the ipa_polymorphic_call_context constructor
is calling walk_ssa_copies on a PHI node that has no arguments. This
happens because finalize_jump_threads eventually removes some PHI arguments
as it's redirecting some edges, leaving a PHI with no arguments:
SR.33_23 = PHI <>
This should get cleaned up later, but the IPA polymorphic code gets called
during the actual CFG clean-up, and walk_ssa_copies cannot handle an empty
PHI.
Approved by Honza.
Fully tested on x86-64 Linux and verified that the patch fixes the ICE on an
x86-64 Linux cross aarch64-linux-gnu cc1plus.
Committed to mainline.
I think the real issue is that the walking code is executed via fold_stmt when
called with an API that tells you not to walk SSA use-def chains.
? We have something that tells us not to walk the chains? I don't see
it in an API for fold_stmt. How is the ipa-polymorphic code supposed to
know when it can't follow the chains?
The restrictions on what we can do while we're in the inconsistent state
prior to updating the ssa graph aren't defined anywhere and I doubt
anyone really knows what they are. That's obviously concerning.
We might consider trying to narrow the window in which these
inconsistencies are allowed. To do that I think we need to split
cfgcleanup into two distinct parts. First is unreachable block removal
(which is needed so that we can compute the dominators). Second is
everything else.
The order of operations would be something like
remove unreachable blocks
ssa graph update
rest of cfg_cleanup
That just feels too intrusive to try at this stage though.
jeff
