Re: [PATCH 0/3] VAX backend preparatory updates for switching to LRA
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
Re: [PATCH 0/3] VAX backend preparatory updates for switching to LRA
On Tue, Apr 27, 2021 at 8:19 PM Maciej W. Rozycki 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
Re: [PATCH 0/3] VAX backend preparatory updates for switching to LRA
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
Re: [PATCH 0/3] VAX backend preparatory updates for switching to LRA
> On Apr 21, 2021, at 5:32 PM, Maciej W. Rozycki 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
Re: [PATCH 0/3] VAX backend preparatory updates for switching to LRA
On Thu, Apr 22, 2021 at 1:22 AM Maciej W. Rozycki 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
[PATCH 0/3] VAX backend preparatory updates for switching to LRA
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