Hi,
PR22543 has a testcase in which we fail with:
error: definition in block 1 does not dominate use in block 3
for SSA_NAME: SFT.3_39 in statement:
# VUSE <SFT.3_39>;
lsm_tmp.35_36 = D.2625.j;
In this testcase block 3 is a loop exit block, and block 1 is a loop header
block. During vectorization the loop is peeled, and an epilog loop (along
with some guard code) is inserted between the original loop and the exit
block. The problem is that the updating of phi-nodes following this
loop-peeling 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. 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 block. SFT.3 is not in loop-closed-sa-form, and in fact
virtual variables in general are no longer guaranteed to be in
loop-closed-form (or maybe never have been?).
The reason vectorization doesn'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 this patch by Diego was
committed:
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.
........
Before this patch SFT.3 was used in the loop, and was therefore marked for
renaming. This is how the loop used to look like:
# 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. */
+ 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: */
but this patch didn't help although SFT.3 was marked for renaming. (why?)
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. Does this sound reasonabale? (By the way, why don't we keep virtual
variables in loop-closed-form?)
comments/ideas?
thanks,
dorit
