[v3,00/10] AMD GCN Port v3

Message ID cover.1544611347.git.ams@codesourcery.com
Headers show
Series
  • AMD GCN Port v3
Related show

Message

Andrew Stubbs Dec. 12, 2018, 11:52 a.m.
This is the third rework of the patchset previously posted on September
5th and November 16th. As before, the series contains the
non-OpenACC/OpenMP portions of a port to AMD GCN3 and GCN5 GPU
processors.  It's sufficient to build single-threaded programs, with
vectorization in the usual way.  C and Fortran are supported, C++ is not
supported, and the other front-ends have not been tested.  The
OpenACC/OpenMP/libgomp portion will follow, once this is committed,
eventually.

Compared to the v2 patchset, patch 1, "Fix IRA ICE", has been dropped,
and a new, unrelated, patch 1 has been added: "Fix LRA bug".

The IRA issue has now been solved by reworking the move instructions in
the back-end so that they no longer require explicit mention of the EXEC
register (this is now managed mostly by the md_reorg pass).  I also took
the opportunity to rework the EXEC use throughout the machine
description (something I've been wanting to get to for ages); the
primary instruction patterns no longer use vec_merge, and there are
"_exec" variants defined (mostly via define_subst) for the use of
specific expanders and so that combine can optimize conditional vector
moves.

Additionally, the patterns that choose which unit to use for
scalar operations now only clobber the relevant condition register (via
a match_scratch), not both of them.

The new LRA issue was exposed by the above changes, but would affect any
target where patterns referring to an eliminable register might also
include a "scratch" register.

I've also addressed the various feedback I received from patch
reviewers.

-- 
Andrew Stubbs
Mentor Graphics / CodeSourcery

Comments

Andrew Stubbs Jan. 7, 2019, 10:47 a.m. | #1
New year ping!

The last remaining middle-end patch was already applied, so it's only 
the backend, config, and testsuite patches remaining to be committed. 
And, it's mostly only the back end still requiring review.

Hopefully I should still be able to get them reviewed and committed in 
time for GCC 9, given that disruption to other targets should no longer 
be an issue?

Andrew

On 12/12/2018 11:52, Andrew Stubbs wrote:
> This is the third rework of the patchset previously posted on September

> 5th and November 16th. As before, the series contains the

> non-OpenACC/OpenMP portions of a port to AMD GCN3 and GCN5 GPU

> processors.  It's sufficient to build single-threaded programs, with

> vectorization in the usual way.  C and Fortran are supported, C++ is not

> supported, and the other front-ends have not been tested.  The

> OpenACC/OpenMP/libgomp portion will follow, once this is committed,

> eventually.

> 

> Compared to the v2 patchset, patch 1, "Fix IRA ICE", has been dropped,

> and a new, unrelated, patch 1 has been added: "Fix LRA bug".

> 

> The IRA issue has now been solved by reworking the move instructions in

> the back-end so that they no longer require explicit mention of the EXEC

> register (this is now managed mostly by the md_reorg pass).  I also took

> the opportunity to rework the EXEC use throughout the machine

> description (something I've been wanting to get to for ages); the

> primary instruction patterns no longer use vec_merge, and there are

> "_exec" variants defined (mostly via define_subst) for the use of

> specific expanders and so that combine can optimize conditional vector

> moves.

> 

> Additionally, the patterns that choose which unit to use for

> scalar operations now only clobber the relevant condition register (via

> a match_scratch), not both of them.

> 

> The new LRA issue was exposed by the above changes, but would affect any

> target where patterns referring to an eliminable register might also

> include a "scratch" register.

> 

> I've also addressed the various feedback I received from patch

> reviewers.

>
Richard Biener Jan. 7, 2019, 11:58 a.m. | #2
On Mon, Jan 7, 2019 at 11:48 AM Andrew Stubbs <ams@codesourcery.com> wrote:
>

> New year ping!

>

> The last remaining middle-end patch was already applied, so it's only

> the backend, config, and testsuite patches remaining to be committed.

> And, it's mostly only the back end still requiring review.

>

> Hopefully I should still be able to get them reviewed and committed in

> time for GCC 9, given that disruption to other targets should no longer

> be an issue?


Yes, it's OK to add during stage4 once approved.

Richard.

> Andrew

>

> On 12/12/2018 11:52, Andrew Stubbs wrote:

> > This is the third rework of the patchset previously posted on September

> > 5th and November 16th. As before, the series contains the

> > non-OpenACC/OpenMP portions of a port to AMD GCN3 and GCN5 GPU

> > processors.  It's sufficient to build single-threaded programs, with

> > vectorization in the usual way.  C and Fortran are supported, C++ is not

> > supported, and the other front-ends have not been tested.  The

> > OpenACC/OpenMP/libgomp portion will follow, once this is committed,

> > eventually.

> >

> > Compared to the v2 patchset, patch 1, "Fix IRA ICE", has been dropped,

> > and a new, unrelated, patch 1 has been added: "Fix LRA bug".

> >

> > The IRA issue has now been solved by reworking the move instructions in

> > the back-end so that they no longer require explicit mention of the EXEC

> > register (this is now managed mostly by the md_reorg pass).  I also took

> > the opportunity to rework the EXEC use throughout the machine

> > description (something I've been wanting to get to for ages); the

> > primary instruction patterns no longer use vec_merge, and there are

> > "_exec" variants defined (mostly via define_subst) for the use of

> > specific expanders and so that combine can optimize conditional vector

> > moves.

> >

> > Additionally, the patterns that choose which unit to use for

> > scalar operations now only clobber the relevant condition register (via

> > a match_scratch), not both of them.

> >

> > The new LRA issue was exposed by the above changes, but would affect any

> > target where patterns referring to an eliminable register might also

> > include a "scratch" register.

> >

> > I've also addressed the various feedback I received from patch

> > reviewers.

> >

>
Jeff Law Jan. 11, 2019, 11:19 p.m. | #3
On 1/7/19 4:58 AM, Richard Biener wrote:
> On Mon, Jan 7, 2019 at 11:48 AM Andrew Stubbs <ams@codesourcery.com> wrote:

>>

>> New year ping!

>>

>> The last remaining middle-end patch was already applied, so it's only

>> the backend, config, and testsuite patches remaining to be committed.

>> And, it's mostly only the back end still requiring review.

>>

>> Hopefully I should still be able to get them reviewed and committed in

>> time for GCC 9, given that disruption to other targets should no longer

>> be an issue?

> 

> Yes, it's OK to add during stage4 once approved.

And I think the V3 patch is reasonable enough to go in now.  There's
some concerns that have been raised with the implementation, but I'm
comfortable with Andrew faulting in fixes if those concerns turn into
real issues.

Andrew, you're green-lighted for the trunk.

jeff
Andrew Stubbs Jan. 14, 2019, 1:55 p.m. | #4
On 11/01/2019 23:19, Jeff Law wrote:
> And I think the V3 patch is reasonable enough to go in now.  There's

> some concerns that have been raised with the implementation, but I'm

> comfortable with Andrew faulting in fixes if those concerns turn into

> real issues.

> 

> Andrew, you're green-lighted for the trunk.


Excellent!

Thank you very much Jeff. :-)

I will now rebase, retest, change all the dates to 2019, and get it 
committed.

I shall follow up with the various documentation adjustments in the next 
week or so, I hope.

Many thanks

Andrew
Andrew Stubbs Jan. 17, 2019, 12:51 p.m. | #5
On 14/01/2019 13:55, Andrew Stubbs wrote:
> I will now rebase, retest, change all the dates to 2019, and get it 

> committed.


This is now done! :-)

THe Newlib port is also committed, so all the pieces needed for testing 
GCN should be available to everybody now.

To be clear, the libgomp port needed to support OpenMP still needs to be 
cleaned up and submitted, and the middle-end patches required to support 
OpenACC are likewise to-do (and currently depend on the openacc 
development branches, in any case).

Many thanks to Jeff, both Richards, Mike, and others for reviewing the 
patches.

Andrew
Richard Biener Jan. 17, 2019, 12:55 p.m. | #6
On Thu, Jan 17, 2019 at 1:51 PM Andrew Stubbs <ams@codesourcery.com> wrote:
>

> On 14/01/2019 13:55, Andrew Stubbs wrote:

> > I will now rebase, retest, change all the dates to 2019, and get it

> > committed.

>

> This is now done! :-)

>

> THe Newlib port is also committed, so all the pieces needed for testing

> GCN should be available to everybody now.

>

> To be clear, the libgomp port needed to support OpenMP still needs to be

> cleaned up and submitted, and the middle-end patches required to support

> OpenACC are likewise to-do (and currently depend on the openacc

> development branches, in any case).

>

> Many thanks to Jeff, both Richards, Mike, and others for reviewing the

> patches.


Please make notes in gcc-9/changes.html and update the ports matrix
in (... go find it!) and also add a news entry to index.html.

Richard.

> Andrew