[committed] PATCH for Re: Stepping down as maintainer for ARC and Epiphany

2024-05-20 Thread Gerald Pfeifer
On Wed, 5 Jul 2023, Joern Rennecke wrote:
> I haven't worked with these targets in years and can't really do 
> sensible maintenance or reviews of patches for them. I am currently 
> working on optimizations for other ports like RISC-V.

I noticed MAINTAINERS was not updated, so pushed the patch below.

Gerald


commit f94598ffaf5affbc9421ff230502357b07c55d9c
Author: Gerald Pfeifer 
Date:   Mon May 20 16:43:05 2024 +0200

MAINTAINERS: Update Joern Rennecke's status

This is per his mail to gcc@gcc.gnu.org on 7 Jul 2023.

ChangeLog:
* MAINTAINERS: Move Joern Rennecke from arc and epiphany maintainer
to Write After Approval.

diff --git a/MAINTAINERS b/MAINTAINERS
index 8e0add6bef8..e2870eef2ef 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -56,7 +56,6 @@ aarch64 port  Kyrylo Tkachov  

 alpha port Richard Henderson   
 amdgcn portJulian Brown
 amdgcn portAndrew Stubbs   
-arc port   Joern Rennecke  
 arc port   Claudiu Zissulescu  
 arm port   Nick Clifton
 arm port   Richard Earnshaw
@@ -68,7 +67,6 @@ c6x port  Bernd Schmidt   

 cris port  Hans-Peter Nilsson  
 c-sky port Xianmiao Qu 
 c-sky port Yunhai Shang
-epiphany port  Joern Rennecke  
 fr30 port  Nick Clifton
 frv port   Nick Clifton
 frv port   Alexandre Oliva 
@@ -634,6 +632,7 @@ Joe Ramsay  

 Rolf Rasmussen 
 Fritz Reese
 Volker Reichelt

+Joern Rennecke 
 Bernhard Reutner-Fischer   
 Tom Rix
 Thomas Rodgers 


Re: [committed] PATCH for Re: Stepping down as maintainer for ARC and Epiphany

2024-05-20 Thread Richard Biener via Gcc
On Mon, May 20, 2024 at 4:45 PM Gerald Pfeifer  wrote:
>
> On Wed, 5 Jul 2023, Joern Rennecke wrote:
> > I haven't worked with these targets in years and can't really do
> > sensible maintenance or reviews of patches for them. I am currently
> > working on optimizations for other ports like RISC-V.
>
> I noticed MAINTAINERS was not updated, so pushed the patch below.

That leaves the epiphany port unmaintained.  Should we automatically add such
ports to the list of obsoleted ports?

Richard.

> Gerald
>
>
> commit f94598ffaf5affbc9421ff230502357b07c55d9c
> Author: Gerald Pfeifer 
> Date:   Mon May 20 16:43:05 2024 +0200
>
> MAINTAINERS: Update Joern Rennecke's status
>
> This is per his mail to gcc@gcc.gnu.org on 7 Jul 2023.
>
> ChangeLog:
> * MAINTAINERS: Move Joern Rennecke from arc and epiphany 
> maintainer
> to Write After Approval.
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8e0add6bef8..e2870eef2ef 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -56,7 +56,6 @@ aarch64 port  Kyrylo Tkachov  
> 
>  alpha port Richard Henderson   
>  amdgcn portJulian Brown
>  amdgcn portAndrew Stubbs   
> -arc port   Joern Rennecke  
>  arc port   Claudiu Zissulescu  
>  arm port   Nick Clifton
>  arm port   Richard Earnshaw
> @@ -68,7 +67,6 @@ c6x port  Bernd Schmidt   
> 
>  cris port  Hans-Peter Nilsson  
>  c-sky port Xianmiao Qu 
>  c-sky port Yunhai Shang
> -epiphany port  Joern Rennecke  
>  fr30 port  Nick Clifton
>  frv port   Nick Clifton
>  frv port   Alexandre Oliva 
> @@ -634,6 +632,7 @@ Joe Ramsay  
> 
>  Rolf Rasmussen 
>  Fritz Reese
>  Volker Reichelt
> 
> +Joern Rennecke 
>  Bernhard Reutner-Fischer   
>  Tom Rix
>  Thomas Rodgers 


RE: [RFC] Merge strathegy for all-SLP vectorizer

2024-05-20 Thread Tamar Christina via Gcc



> -Original Message-
> From: Richard Biener 
> Sent: Friday, May 17, 2024 1:54 PM
> To: Richard Sandiford 
> Cc: Richard Biener via Gcc ; Tamar Christina
> 
> Subject: Re: [RFC] Merge strathegy for all-SLP vectorizer
> 
> On Fri, 17 May 2024, Richard Sandiford wrote:
> 
> > Richard Biener via Gcc  writes:
> > > Hi,
> > >
> > > I'd like to discuss how to go forward with getting the vectorizer to
> > > all-SLP for this stage1.  While there is a personal branch with my
> > > ongoing work (users/rguenth/vect-force-slp) branches haven't proved
> > > themselves working well for collaboration.
> >

Yeah, It's hard to keep rebasing and build on top of.

> > Speaking for myself, the problem hasn't been so much the branch as
> > lack of time.  I've been pretty swamped the last eight months of so
> > (except for the time that I took off, which admittedly was quite a
> > bit!), and so I never even got around to properly reading and replying
> > to your message after the Cauldron.  It's been on the "this is important,
> > I should make time to read and understand it properly" list all this time.
> > Sorry about that. :(
> >
> > I'm hoping to have time to work/help out on SLP stuff soon.
> >
> > > The branch isn't ready to be merged in full but I have been picking
> > > improvements to trunk last stage1 and some remaining bits in the past
> > > weeks.  I have refrained from merging code paths that cannot be
> > > exercised on trunk.
> > >
> > > There are two important set of changes on the branch, both critical
> > > to get more testing on non-x86 targets.
> > >
> > >  1. enable single-lane SLP discovery
> > >  2. avoid splitting store groups (9315bfc661432c3 and 4336060fe2db8ec
> > > if you fetch the branch)
> > >

For no# is there a param or is it just the default?  I can run these through
regression today.

> > > The first point is also most annoying on the testsuite since doing
> > > SLP instead of interleaving changes what we dump and thus tests
> > > start to fail in random ways when you switch between both modes.
> > > On the branch single-lane SLP discovery is gated with
> > > --param vect-single-lane-slp.
> > >
> > > The branch has numerous changes to enable single-lane SLP for some
> > > code paths that have SLP not implemented and where I did not bother
> > > to try supporting multi-lane SLP at this point.  It also adds more
> > > SLP discovery entry points.
> > >
> > > I'm not sure how to try merging these pieces to allow others to
> > > more easily help out.  One possibility is to merge
> > > --param vect-single-lane-slp defaulted off and pick dependent
> > > changes even when they cause testsuite regressions with
> > > vect-single-lane-slp=1.  Alternatively adjust the testsuite by
> > > adding --param vect-single-lane-slp=0 and default to 1
> > > (or keep the default).

I guess which one is better depends on whether the parameter goes
away this release? If so I think we should just leave them broken for
now and fix them up when it's the default?

> >
> > FWIW, this one sounds good to me (the default to 1 version).
> > I.e. mechanically add --param vect-single-lane-slp=0 to any tests
> > that fail with the new default.  That means that the test that need
> > fixing are easily greppable for anyone who wants to help.  Sometimes
> > it'll just be a test update.  Sometimes it will be new vectoriser code.
> 
> OK.  Meanwhile I figured the most important part is 2. from above
> since that enables the single-lane in a grouped access (also covering
> single element interleaving).  This will cover all problematical cases
> with respect to vectorizing loads and stores.  It also has less
> testsuite fallout, mainly because we have a lot less coverage for
> grouped stores without SLP.
> 
> So I'll see to produce a mergeable patch for part 2 and post that
> for review next week.

Sounds good!

Thanks for getting the ball rolling on this.
It would be useful to have it in trunk indeed, off by default for now
sounds good because then I can work on trunk for the SLP support
for early break as well.

Cheers,
Tamar

> 
> Thanks,
> Richard.
> 
> > Thanks,
> > Richard
> >
> > > Or require a clean testsuite with
> > > --param vect-single-lane-slp defaulted to 1 but keep the --param
> > > for debugging (and allow FAILs with 0).
> > >
> > > For fun I merged just single-lane discovery of non-grouped stores
> > > and have that enabled by default.  On x86_64 this results in the
> > > set of FAILs below.
> > >
> > > Any suggestions?
> > >
> > > Thanks,
> > > Richard.
> > >
> > > FAIL: gcc.dg/vect/O3-pr39675-2.c scan-tree-dump-times vect "vectorizing
> > > stmts using SLP" 1
> > > XPASS: gcc.dg/vect/no-scevccp-outer-12.c scan-tree-dump-times vect "OUTER
> > > LOOP VECTORIZED." 1
> > > FAIL: gcc.dg/vect/no-section-anchors-vect-31.c scan-tree-dump-times vect
> > > "Alignment of access forced using peeling" 2
> > > FAIL: gcc.dg/vect/no-section-anchors-vect-31.c scan-tree-dump-times vect
> > > "Vectorizing an unaligned acces