[Bug target/24378] [4.1/4.2 Regression] gcc.dg/vect/pr24300.c (test for excess errors) fails

["dorit at il dot ibm dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #5 from dorit at il dot ibm dot com  2005-12-07 16:35 -------
> What's the best approach to fixing this?  Punting in vectorizable_reduction
> if we know beforehand that the loop will be versioned?
>   /* Same if the loop is to be versioned.  */
>   if (VEC_length (tree, LOOP_VINFO_MAY_MISALIGN_STMTS (loop_vinfo)))
>     return false;

maybe just as a temporary work around, but this shouldn't be a reason to block
vectorization of reductions

> Or can vect_create_epilog_for_reduction be enhanced to cope with versioning?
> Thanks in advance.

I think that vect_create_epilog_for_reduction should be fixed as follows:
create a new basic block at the exit edge, put the reduction epilog code there,
and then properly update the phi node at the merge-block (exit_bb). i.e. we
start with:

==============================
L32: 
if (cond) goto vectorized_loop (L33) 
else      goto scalar_loop (L34)

L34:
L31:
  loop body
  n_90 += ...
  if (...) goto L30
  else     goto L7
L30: 
  goto L31

L33:
L35:
L0:
  loop body
  n_58 += ...
  if (...) goto L19
  else     goto L7
L19: 
  goto L0

L7:
n = phi (n_58, n_90)
==============================

Transform that into:

==============================
L32: 
if (cond) goto vectorized_loop (L33) 
else      goto scalar_loop (L34)

L34:
L31:
  loop body
  n_90 += ...
  if (...) goto L30
  else     goto L7
L30: 
  goto L31

L33:
L35:
L0:
  loop body
  vect_var_5 += ...             # new
  n_58 += ...   
  if (...) goto L19
  else     goto new_bb
L19: 
  goto L0

new_bb:
v_out = phi <vect_var_5>        # new
s_out = epilog_code <v_out>     # new
goto L7

L7:
n = phi (s_out, n_90)           # updated
==============================

i.e., the new scalar result s_out that we compute in the reduction epilog will
replace the old value n_58 in the phi node of the merge-block L7. 

One other issue to be careful about is that new_bb should also have all the
necessary loop-exit-phis in order to maintain loop-closed-form. Assuming that
after loop-versioning the code is in loop-closed-form, then all the necessary
loop-exit-phis are in L7. We'd probably need to scan the phis of L7, and create
a phi-node in new_bb for each phi-node in L7. e.g., if we had:

==============================
L7:
x_2 = phi (x_0, x_1)
n = phi (n_58, n_90)
==============================

We'd probably want to create the following:

==============================
new_bb:
x_100 = phi (x_0)                # "copied"     from L7
n_101 = phi (n_58)       # "copied"     from L7 (this is redundant, will get
DCE'ed)
v_out = phi <vect_var_5> # new phi
s_out = epilog_code <v_out>
goto L7

L7:
x_2 = phi (x_100, x_1)  # updated
n = phi (s_out, n_90)   # updated
==============================


Another option is to make sure that the code transformation routines in the
vectorizer could continue to make the assumption that the loop-exit-bb has a
single predecessor. One option is to fix loop-versioning to do that (create a
new_bb at the exit-edge of each loop version before the merging point), or by
fixing it up in the vectorizer immediately after loop versioning takes place. 
I think maybe this option is safer. It's basically doing the same as above but
earlier in the vectorizer, and independently of whether reduction takes place.
i.e. create this: 

==============================
new_bb:
x_100 = phi (x_0)                # "copied"     from L7
n_101 = phi (n_58)       # "copied"     from L7
goto L7

L7:
x_2 = phi (x_100, x_1)  # updated
n = phi (n_101, n_90)   # updated
==============================

This way the reduction-epilog-code creation can continue to work exactly as it
does now.

You can assign this to me, but I won't be able to get to this for the next
week, so maybe I better have it assigned to me when I actually have time to
work on this (in about a week, if it's not fixed by then). Either way is fine
with me. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24378