------- Additional Comments From law at redhat dot com 2005-05-25 21:43 ------- Subject: Re: [4.1 regression] ICE: -ftree-vectorize, segfault
On Wed, 2005-05-25 at 07:28 +0000, dorit at il dot ibm dot com wrote: > ------- Additional Comments From dorit at il dot ibm dot com 2005-05-25 > 07:28 ------- > > Actually, this is a bug in the vectorizer code to update PHIs in duplicate > > loops. forwprop AFAICT is just exposing the latent vectorizer bug. > > >From what I've been able to determine so far, the vectorizer code to > > update PHIs doesn't properly handle the case where a PHI is dead. It > > is likely someone with more experience in the vectorizer code is going > > to need to fix this. > > I'll take a look Thanks. I suspect we have multiple problems with the PHI updates. I think I know how to fix the code for updating PHIs in the duplicate loop, but I haven't really slogged through the guard code to figure out how PHIs in the guards should be updated. In the case of the duplicate loop we have the following code: > > /* Scan the phis in the headers of the old and new loops (they are organized in exactly the same order). */ for (phi_new = phi_nodes (new_loop->header), phi_orig = phi_nodes (orig_loop->header); phi_new && phi_orig; phi_new = PHI_CHAIN (phi_new), phi_orig = PHI_CHAIN (phi_orig)) { /* step 1. */ def = PHI_ARG_DEF_FROM_EDGE (phi_orig, entry_arg_e); add_phi_arg (phi_new, def, new_loop_entry_e); /* step 2. */ def = PHI_ARG_DEF_FROM_EDGE (phi_orig, orig_loop_latch); if (TREE_CODE (def) != SSA_NAME) continue; new_ssa_name = get_current_def (def); if (!new_ssa_name) /* Something defined outside of the loop. */ continue; /* An ordinary ssa name defined in the loop. */ add_phi_arg (phi_new, new_ssa_name, loop_latch_edge (new_loop)); /* step 3 (case 1). */ if (!after) { gcc_assert (new_loop_exit_e == orig_entry_e); SET_PHI_ARG_DEF (phi_orig, new_loop_exit_e->dest_idx, new_ssa_name); } Note that if !new_ssa_name, we continue the loop without ever adding the PHI argument. The net result being that we have a PHI where PHI_ARG_DEF for one of the PHI's incoming edges is null. I'm pretty sure that this can only happen if the result of the PHI is not set anywhere in the loop. In that case the PHI argument in question should be the same SSA_NAME as the PHI_RESULT [ ie, we ultimately end up generating a degenerate phi of the form x_3 = PHI (x_3 (latch edge), x_2 (initial value from entry edge)) What I don't know yet is if the problem is really that we haven't set up the current def properly (thus causing get_current_def to return NULL) or if we just need code to compensate for this situation in slpeel_update_phis_for_duplicate_loop. Thoughts? Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21734