[PATCH 5/5][v3] RISC-V: Avoid inserting after a GIMPLE_COND with SLP and early break

[PATCH 5/5][v3] RISC-V: Avoid inserting after a GIMPLE_COND with SLP and early break

[Richard Biener]

When vectorizing an early break loop with LENs (do we miss some
check here to disallow this?) we can end up deciding to insert
stmts after a GIMPLE_COND when doing SLP scheduling and trying
to be conservative with placing of stmts only dependent on
the implicit loop mask/len.  The following avoids this, I guess
it's not perfect but it does the job fixing some observed
RISC-V regression.

	* tree-vect-slp.cc (vect_schedule_slp_node): For mask/len
	loops make sure to not advance the insertion iterator
	beyond a GIMPLE_COND.
---
 gcc/tree-vect-slp.cc | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/gcc/tree-vect-slp.cc b/gcc/tree-vect-slp.cc
index b469977aab2..dd7703a3cc0 100644
--- a/gcc/tree-vect-slp.cc
+++ b/gcc/tree-vect-slp.cc
@@ -9689,7 +9689,12 @@ vect_schedule_slp_node (vec_info *vinfo,
       else
 	{
 	  si = gsi_for_stmt (last_stmt);
-	  gsi_next (&si);
+	  /* When we're getting gsi_after_labels from the starting
+	     condition of a fully masked/len loop avoid insertion
+	     after a GIMPLE_COND that can appear as the only header
+	     stmt with early break vectorization.  */
+	  if (gimple_code (last_stmt) != GIMPLE_COND)
+	    gsi_next (&si);
 	}
     }
 
-- 
2.35.3

Re: [PATCH 5/5][v3] RISC-V: Avoid inserting after a GIMPLE_COND with SLP and early break

[Jeff Law]

On 5/31/24 7:44 AM, Richard Biener wrote:
> When vectorizing an early break loop with LENs (do we miss some
> check here to disallow this?) we can end up deciding to insert
> stmts after a GIMPLE_COND when doing SLP scheduling and trying
> to be conservative with placing of stmts only dependent on
> the implicit loop mask/len.  The following avoids this, I guess
> it's not perfect but it does the job fixing some observed
> RISC-V regression.
> 
> 	* tree-vect-slp.cc (vect_schedule_slp_node): For mask/len
> 	loops make sure to not advance the insertion iterator
> 	beyond a GIMPLE_COND.
Note this patch may depend on others in the series.  I don't think the 
pre-commit CI tester is particularly good at handling that, particularly 
if the other patches in the series don't have the tagging for the 
pre-commit CI.

What most likely happened is this patch and only this patch was applied 
against the baseline for testing.

There are (manual) ways to get things re-tested.  I'm hoping Patrick and 
Edwin automate that procedure relatively soon.  Until that happens you 
have to email patchworks-ci@rivosinc.com with a URL for the patch in 
patchwork that you want retested.



Jeff

Re: [PATCH 5/5][v3] RISC-V: Avoid inserting after a GIMPLE_COND with SLP and early break

[Patrick O'Neill]

On Fri, May 31, 2024 at 9:41 PM Jeff Law <jeffreyalaw@gmail.com> wrote:
>
> On 5/31/24 7:44 AM, Richard Biener wrote:
> > When vectorizing an early break loop with LENs (do we miss some
> > check here to disallow this?) we can end up deciding to insert
> > stmts after a GIMPLE_COND when doing SLP scheduling and trying
> > to be conservative with placing of stmts only dependent on
> > the implicit loop mask/len.  The following avoids this, I guess
> > it's not perfect but it does the job fixing some observed
> > RISC-V regression.
> >
> >       * tree-vect-slp.cc (vect_schedule_slp_node): For mask/len
> >       loops make sure to not advance the insertion iterator
> >       beyond a GIMPLE_COND.
> Note this patch may depend on others in the series.  I don't think the
> pre-commit CI tester is particularly good at handling that, particularly
> if the other patches in the series don't have the tagging for the
> pre-commit CI.
>
> What most likely happened is this patch and only this patch was applied
> against the baseline for testing.

I fixed that last week (5/16) so we shouldn't be seeing that issue anymore.
If you're still seeing it please let me know and I'd be interested to dig in.
From checking the patch_urls artifact it looks like all 5 patches were applied
to 46d931b. It's an old baseline so that might be the issue.

We've been having hard-to-diagnose network issues on some of the
newly-added CI boxes. Fingers crossed that's resolved now.
I'll rerun this patch tomorrow once the new baseline is generated.

> There are (manual) ways to get things re-tested.  I'm hoping Patrick and
> Edwin automate that procedure relatively soon.  Until that happens you
> have to email patchworks-ci@rivosinc.com with a URL for the patch in
> patchwork that you want retested.
Ditto - treat it as if it's automated. When I see it I'll reply with a
link to the rerun.
I'll start to look at wiring it up to an automation next week.

I also have the ability to manually trigger on patches not labelled 'RISC-V' so
feel free to ping for that as well.

Patrick

> Jeff
>