On Mon, Mar 30, 2020 at 12:24 PM Kewen.Lin <li...@linux.ibm.com> wrote: > > Hi, > > As PR94043 shows, my commit r10-4524 exposed one issue in > vectorizable_live_operation, which inserts one extra BB > before the single exit, leading unexpected operand expansion > and unexpected loop depth assertion. As Richi suggested, > this patch is to teach vectorizable_live_operation to > generate loop closed phi for vec_lhs, it looks like: > loop; > # lhs' = PHI <lhs> > => > loop; > # vec_lhs' = PHI <vec_lhs> > new_tree = BIT_FIELD_REF <vec_lhs', ...>; > lhs' = new_tree; > > I noticed that there are some SLP cases that have same lhs > and vec_lhs but different offsets, which can make us have > more PHIs for the same vec_lhs there. But I think it would > be fine since only one of them is actually live, the others > should be eliminated by the following dce. So the patch > doesn't check whether there is one phi for vec_lhs, just > create one directly instead. > > Bootstrapped/regtested on powerpc64le-linux-gnu (LE) P8. > > Is it ok for trunk?
OK. Thanks, Richard. > BR, > Kewen > ----------- > > gcc/ChangeLog > > 2020-MM-DD Kewen Lin <li...@gcc.gnu.org> > > PR tree-optimization/94043 > * tree-vect-loop.c (vectorizable_live_operation): Generate loop-closed > phi for vec_lhs and use it for lane extraction. > > gcc/testsuite/ChangeLog > > 2020-MM-DD Kewen Lin <li...@gcc.gnu.org> > > PR tree-optimization/94043 > * gfortran.dg/graphite/vect-pr94043.f90: New test. >