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.
>

Reply via email to