------- Additional Comments From dorit at il dot ibm dot com 2005-08-09 15:38
-------
I was able to reproduce the error on powerpc-drawin using the first testcase
from comment 3 for PR22543.
I was also able to pin down the patch that triggered/exposed this problem:
2005-07-09 Diego Novillo <[EMAIL PROTECTED]>
* Makefile.in (tree-ssa-alias.o): Depend on tree-ssa-structalias.h
* tree-cfg.c (CHECK_OP): Only test for is_gimple_val.
* tree-dfa.c (dump_subvars_for): New.
(debug_subvars_for): New.
(dump_variable): Show subvariables if VAR has them.
........
Here is what I think is going on:
The updating of phi-nodes during loop-peeling (in the vectorizer) does not
create all the required phis for the variable SFT.3. This happens because the
vectorizer can only update the ssa-form for variables that are in proper loop-
closed-ssa-form. SFT.3 is not in loop-closed-form, and in fact virtual
variables in general are no longer guaranteed to be in loop-closed-form (or
maybe never have been?). More specifically, the function
slpeel_update_phi_nodes_for_guard2 was supposed to create the missing phis, but
it only works for variables that have a loop-closed phi at the loop exit.
The reason we don't fail in the presence of virtual-phis all the time, is, I
think, that usually the virtual variables that need to be updated (due to
peeling) are also used or defined inside the loop (in a load or store
operation), and are therefore marked by the vectorizer for renaming when that
load/store is handled (and update_ssa is consequently called). This was also
what used to happen in this testcase, until the patch by Diego was committed -
SFT.3 was used in the loop, and was therefore marked for renaming. This is how
the loop looked like before the patch:
# ivtmp.20D.2696_34 = PHI <ivtmp.20D.2696_2(2), 4(0)>;
# SFT.4D.2672_41 = PHI <SFT.4D.2672_33(2), SFT.4D.2672_22(0)>;
# SFT.3D.2671_39 = PHI <SFT.3D.2671_32(2), SFT.3D.2671_23(0)>;
# iD.2620_37 = PHI <iD.2620_17(2), 0(0)>;
<L0>:;
# SFT.3D.2671_32 = V_MAY_DEF <SFT.3D.2671_39>;
# SFT.4D.2672_33 = V_MAY_DEF <SFT.4D.2672_41>;
thisD.2584_16->zD.2580[iD.2620_37] = 0;
iD.2620_17 = iD.2620_37 + 1;
ivtmp.20D.2696_2 = ivtmp.20D.2696_34 - 1;
if (ivtmp.20D.2696_2 != 0) goto <L14>; else goto <L15>;
And this is how the loop looks like now, after the patch:
# ivtmp.37D.2713_4 = PHI <ivtmp.37D.2713_1(2), 4(0)>;
# TMT.10D.2678_10 = PHI <TMT.10D.2678_11(2), TMT.10D.2678_9(0)>;
# SFT.4D.2672_41 = PHI <SFT.4D.2672_41(2), SFT.4D.2672_22(0)>;
# SFT.3D.2671_39 = PHI <SFT.3D.2671_39(2), SFT.3D.2671_23(0)>;
# iD.2620_37 = PHI <iD.2620_17(2), 0(0)>;
<L0>:;
# TMT.10D.2678_11 = V_MAY_DEF <TMT.10D.2678_10>;
thisD.2584_16->zD.2580[iD.2620_37] = 0;
iD.2620_17 = iD.2620_37 + 1;
ivtmp.37D.2713_1 = ivtmp.37D.2713_4 - 1;
if (ivtmp.37D.2713_1 != 0) goto <L14>; else goto <L15>;
SFT.3 no longer gets used inside the loop, so it doesn't get marked for
renaming, and the proper phis do not get created.
I tried to mark for renaming virtual variables that have phis in the loop, like
this SFT.3, as follows:
Index: tree-vectorizer.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/tree-vectorizer.c,v
retrieving revision 2.107
diff -c -3 -p -r2.107 tree-vectorizer.c
*** tree-vectorizer.c 28 Jul 2005 16:29:57 -0000 2.107
--- tree-vectorizer.c 9 Aug 2005 12:20:00 -0000
*************** slpeel_update_phi_nodes_for_guard1 (edge
*** 522,527 ****
--- 522,532 ----
orig_phi && update_phi;
orig_phi = PHI_CHAIN (orig_phi), update_phi = PHI_CHAIN (update_phi))
{
+ /* Virtual phi; Mark it for renaming. */
+ /* CHECKME: skip? */
+ if (!is_gimple_reg (SSA_NAME_VAR (PHI_RESULT (orig_phi))))
+ mark_sym_for_renaming (SSA_NAME_VAR (PHI_RESULT (orig_phi)));
+
/** 1. Handle new-merge-point phis **/
/* 1.1. Generate new phi node in NEW_MERGE_BB: */
This patch didn't help although SFT.3 was marked for renaming. Diego, any
ideas??
The other thing we could try to do is put virtual variables in loop-closed-
form, at least just before the vectorizer, and at least just for some loops.
(By the way, why don't we keep virtual variables in loop-closed-form?)
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |dnovillo at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22228
