mbox series

[0/3] VAX backend preparatory updates for switching to LRA

Message ID alpine.DEB.2.21.2104211551240.44318@angie.orcam.me.uk
Headers show
Series VAX backend preparatory updates for switching to LRA | expand

Message

Maciej W. Rozycki April 21, 2021, 9:32 p.m. UTC
Hi,

 According to the plan discussed in the context of the recent switch to
MODE_CC of the VAX backend I have been looking into switching the backend 
to LRA as well.

 It has turned out quite straightforward itself, with just a couple of 
minor issues triggered with a flip to LRA, one causing a build failure 
with target libatomic and another causing a C testsuite regression.  Also 
I have come across a piece of dead code which has never ever been used for 
anything and it is unclear to me what its intended purpose was.

 I have come up with this small patch series then, bundled together for 
easier reference although the individual changes are independent from each 
other.

 I think 3/3 is worth backporting to GCC 11 at one point, perhaps 11.2, so 
that it can be easily picked downstream, as it improves code generation 
with old reload and we may not have another major release still using it.

 OTOH switching to LRA regresses code generation seriously, by making the 
indexed and indirect VAX address modes severely underutilised, so while 
with these changes in place the backend can be switched to LRA with just a 
trivial to remove the redefinition of TARGET_LRA_P, I think it is not yet 
the right time to do it.

 It is not a hard show-stopper though, so while I plan to look into LRA 
now to figure out what is missing there that the old reload has to satisfy 
the VAX backend, the switch to LRA can now be made anytime if so required 
and I am preempted for whatever reason (and nobody else gets to it).

 Questions, comments, OK to apply?

  Maciej

Comments

Richard Biener April 22, 2021, 8:16 a.m. UTC | #1
On Thu, Apr 22, 2021 at 1:22 AM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
>
> Hi,
>
>  According to the plan discussed in the context of the recent switch to
> MODE_CC of the VAX backend I have been looking into switching the backend
> to LRA as well.
>
>  It has turned out quite straightforward itself, with just a couple of
> minor issues triggered with a flip to LRA, one causing a build failure
> with target libatomic and another causing a C testsuite regression.  Also
> I have come across a piece of dead code which has never ever been used for
> anything and it is unclear to me what its intended purpose was.
>
>  I have come up with this small patch series then, bundled together for
> easier reference although the individual changes are independent from each
> other.
>
>  I think 3/3 is worth backporting to GCC 11 at one point, perhaps 11.2, so
> that it can be easily picked downstream, as it improves code generation
> with old reload and we may not have another major release still using it.
>
>  OTOH switching to LRA regresses code generation seriously, by making the
> indexed and indirect VAX address modes severely underutilised, so while
> with these changes in place the backend can be switched to LRA with just a
> trivial to remove the redefinition of TARGET_LRA_P, I think it is not yet
> the right time to do it.
>
>  It is not a hard show-stopper though, so while I plan to look into LRA
> now to figure out what is missing there that the old reload has to satisfy
> the VAX backend, the switch to LRA can now be made anytime if so required
> and I am preempted for whatever reason (and nobody else gets to it).
>
>  Questions, comments, OK to apply?

Sounds like a reasonable stance to me.  The patches look all good, thus
they are OK to apply.

Thanks,
Richard.

>
>   Maciej
Li, Pan2 via Gcc-patches April 22, 2021, 1:52 p.m. UTC | #2
> On Apr 21, 2021, at 5:32 PM, Maciej W. Rozycki <macro@orcam.me.uk> wrote:
> 
> ...
> OTOH switching to LRA regresses code generation seriously, by making the 
> indexed and indirect VAX address modes severely underutilised, so while 
> with these changes in place the backend can be switched to LRA with just a 
> trivial to remove the redefinition of TARGET_LRA_P, I think it is not yet 
> the right time to do it.

I noticed similar issues with pdp11, which at the moment allows LRA via a -mlra switch but doesn't make it the default.  Another mode that isn't handled well (or at all) by LRA is autoincrement/autodecrement.  It would be great if all these things could be done better, that would help several targets.  (I wonder if m68k would be another; doesn't it have similar addressing modes at least on the 68040?)

	paul
Maciej W. Rozycki April 27, 2021, 6:19 p.m. UTC | #3
On Thu, 22 Apr 2021, Richard Biener wrote:

> >  I think 3/3 is worth backporting to GCC 11 at one point, perhaps 11.2, so
> > that it can be easily picked downstream, as it improves code generation
> > with old reload and we may not have another major release still using it.
> >
> >  OTOH switching to LRA regresses code generation seriously, by making the
> > indexed and indirect VAX address modes severely underutilised, so while
> > with these changes in place the backend can be switched to LRA with just a
> > trivial to remove the redefinition of TARGET_LRA_P, I think it is not yet
> > the right time to do it.
> >
> >  It is not a hard show-stopper though, so while I plan to look into LRA
> > now to figure out what is missing there that the old reload has to satisfy
> > the VAX backend, the switch to LRA can now be made anytime if so required
> > and I am preempted for whatever reason (and nobody else gets to it).
> >
> >  Questions, comments, OK to apply?
> 
> Sounds like a reasonable stance to me.  The patches look all good, thus
> they are OK to apply.

 With GCC 11.1 out now I have committed these changes.  Thank you for your 
review.

 FAOD, as noted above will it be OK if I backport 3/3 to GCC 11 now, for 
inclusion with 11.2?

 While not a regression fix the change is contained in the VAX backend, 
not a mainstream one, and now it is possibly the final opportunity to have 
old reload improved for the VAX target as it's quite likely we'll switch 
to LRA and dump old reload with GCC 12, and we may not be able to get LRA 
on a par with old reload for VAX for a while yet.  Conversely, with the 
improvement in place downstream users (NetBSD) may be able to pick it 
easily enough to make a good use of it now.

 WDYT?

  Maciej
Richard Biener April 28, 2021, 6:58 a.m. UTC | #4
On Tue, Apr 27, 2021 at 8:19 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
>
> On Thu, 22 Apr 2021, Richard Biener wrote:
>
> > >  I think 3/3 is worth backporting to GCC 11 at one point, perhaps 11.2, so
> > > that it can be easily picked downstream, as it improves code generation
> > > with old reload and we may not have another major release still using it.
> > >
> > >  OTOH switching to LRA regresses code generation seriously, by making the
> > > indexed and indirect VAX address modes severely underutilised, so while
> > > with these changes in place the backend can be switched to LRA with just a
> > > trivial to remove the redefinition of TARGET_LRA_P, I think it is not yet
> > > the right time to do it.
> > >
> > >  It is not a hard show-stopper though, so while I plan to look into LRA
> > > now to figure out what is missing there that the old reload has to satisfy
> > > the VAX backend, the switch to LRA can now be made anytime if so required
> > > and I am preempted for whatever reason (and nobody else gets to it).
> > >
> > >  Questions, comments, OK to apply?
> >
> > Sounds like a reasonable stance to me.  The patches look all good, thus
> > they are OK to apply.
>
>  With GCC 11.1 out now I have committed these changes.  Thank you for your
> review.
>
>  FAOD, as noted above will it be OK if I backport 3/3 to GCC 11 now, for
> inclusion with 11.2?
>
>  While not a regression fix the change is contained in the VAX backend,
> not a mainstream one, and now it is possibly the final opportunity to have
> old reload improved for the VAX target as it's quite likely we'll switch
> to LRA and dump old reload with GCC 12, and we may not be able to get LRA
> on a par with old reload for VAX for a while yet.  Conversely, with the
> improvement in place downstream users (NetBSD) may be able to pick it
> easily enough to make a good use of it now.
>
>  WDYT?

Works for me.

Richard.

>   Maciej
Maciej W. Rozycki May 1, 2021, 4:33 p.m. UTC | #5
On Wed, 28 Apr 2021, Richard Biener wrote:

> >  FAOD, as noted above will it be OK if I backport 3/3 to GCC 11 now, for
> > inclusion with 11.2?
> >
> >  While not a regression fix the change is contained in the VAX backend,
> > not a mainstream one, and now it is possibly the final opportunity to have
> > old reload improved for the VAX target as it's quite likely we'll switch
> > to LRA and dump old reload with GCC 12, and we may not be able to get LRA
> > on a par with old reload for VAX for a while yet.  Conversely, with the
> > improvement in place downstream users (NetBSD) may be able to pick it
> > easily enough to make a good use of it now.
> >
> >  WDYT?
> 
> Works for me.

 Backport committed now then, thanks for your review.

  Maciej