Re: [PATCH] Convert SPARC to LRA
> Are there any plans to switch the SPARC GCC to LRA for GCC 7 or later? There are plans to switch SPARC to LRA at some point, but no ETA. -- Eric Botcazou
Re: [PATCH] Convert SPARC to LRA
On 08/12/15 17:55, David Miller wrote: From: Sebastian Huber Date: Tue, 8 Dec 2015 11:17:53 +0100 since the LRA patch is still reverted on the trunk, I guess the switch to LRA will not happen in GCC 6? Indeed, it is unlikely I will have time to work on this for at least a month. Are there any plans to switch the SPARC GCC to LRA for GCC 7 or later? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: [PATCH] Convert SPARC to LRA
From: Sebastian Huber Date: Tue, 8 Dec 2015 11:17:53 +0100 > since the LRA patch is still reverted on the trunk, I guess the > switch to LRA will not happen in GCC 6? Indeed, it is unlikely I will have time to work on this for at least a month.
Re: [PATCH] Convert SPARC to LRA
Hello David, since the LRA patch is still reverted on the trunk, I guess the switch to LRA will not happen in GCC 6? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: [PATCH] Convert SPARC to LRA
On 09/30/2015 10:15 AM, Segher Boessenkool wrote: On Wed, Sep 30, 2015 at 09:15:17AM -0600, Jeff Law wrote: I guess the support of cc0 can be implemented for reasonable amount of time. It is just a priority issue. I still have a lot PRs for the targets already using LRA. I wouldn't suggest making cc0 support a significant priority. I'd be more likely to push for deprecating cc0 targets first. It looks like most cc0 targets would be pretty easy to convert, if anyone can do testing anyway ;-) v850, h8300 and m68k are all testable. The first two via traditional simulators, the latter via aranym. I just haven't seen the benefit for converting them outweighing the time, so I haven't tried. If you wanted to take a stab (and I'm sure the v850 would be easiest), I'll sign up for the regression testing & debugging. Jeff
Re: [PATCH] Convert SPARC to LRA
On Tue, 2015-09-29 at 09:27 -0500, Peter Bergner wrote:
> The first ICE seems to be due to a conversion to long double and LRA ends
> up going into a infinite loop spilling things until it hits a threshold and
> quits with an ICE. I haven't spent enough time to determine whether this
> is a LRA or port issue yet though. The simplest test case I have at the
> moment is:
>
> bergner@genoa:~/gcc/BUGS/LRA/20011123-1$ cat bug2.i
> void
> foo (long double *ldb1, double *db1)
> {
> *ldb1 = *db1;
> }
> bergner@genoa:~/gcc/BUGS/LRA/20011123-1$
> /home/bergner/gcc/build/gcc-fsf-mainline-bootstrap-lra-default-debug/gcc/xgcc
> -B/home/bergner/gcc/build/gcc-fsf-mainline-bootstrap-lra-default-debug/gcc/
> -S -O1 -mvsx -S bug2.i
> bug2.i: In function ‘foo’:
> bug2.i:5:1: internal compiler error: Max. number of generated reload insns
> per insn is achieved (90)
So working with Segher and Mike offline, this ends up being a problem
with rs6000.md's *extenddftf2_internal pattern using the constraint
"ws" in alternative 2. TFmode variables are not allowed in Altivec
registers, so this pattern should be using the "d" constraint instead.
I'm testing a patch.
Peter
Re: [PATCH] Convert SPARC to LRA
On Wed, Sep 30, 2015 at 09:15:17AM -0600, Jeff Law wrote: > >I guess the support of cc0 can be implemented for reasonable amount of > >time. It is just a priority issue. I still have a lot PRs for the > >targets already using LRA. > I wouldn't suggest making cc0 support a significant priority. I'd be > more likely to push for deprecating cc0 targets first. It looks like most cc0 targets would be pretty easy to convert, if anyone can do testing anyway ;-) Segher
Re: [PATCH] Convert SPARC to LRA
On 09/29/2015 09:04 PM, Vladimir Makarov wrote: On 09/29/2015 09:43 AM, Jeff Law wrote: FWIW, I tried to build a simple cc0 target with LRA (v850-elf), but it fell over pretty early. Essentially LRA doesn't seem to be cc0-aware in split_reg as ultimately inserted something between a cc0-setter and cc0-user. Oops. Yes, that is true. When I started to work on LRA, I decided to ignore cc0 first. But since then, no progress was made on this front. No worries. I guess the support of cc0 can be implemented for reasonable amount of time. It is just a priority issue. I still have a lot PRs for the targets already using LRA. I wouldn't suggest making cc0 support a significant priority. I'd be more likely to push for deprecating cc0 targets first. jeff
Re: [PATCH] Convert SPARC to LRA
On 30/09/15 04:07, Jeff Law wrote: If the port does get occasional fixes (primarily driven by BZs), but not getting updated on a regular basis (such as conversion to LRA, conversion to RTL prologue/epilogue, etc), may be only getting occasional testing, etc. Then it's probably fair to call it in maintenance mode. A great example IMHO would be the m68k. Another criteria would be available hardware for which both the PA and alpha ports are a good example. When you can't buy new hardware then targets that could formerly host GCC quickly rot to the state where only cross-compilation is viable (and having "old" GCC is good enough). Very true. Actually the PA is the best example there. Alpha I believe has a functional-enough QEMU port to do real work and m68k has Aranym which I've used to bootstrap m68k within the last 18 months. Hell, I think Aranym actually ran faster than the last shipping real hardware! You can still buy m68k based chips (e.g. Freescale ColdFire) for embedded systems. http://www.freescale.com/products/more-processors/32-bit-mcu-and-mcp/coldfire-plus-coldfire-mcus-mpus:PC68KCF -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: [PATCH] Convert SPARC to LRA
On 09/29/2015 09:43 AM, Jeff Law wrote: FWIW, I tried to build a simple cc0 target with LRA (v850-elf), but it fell over pretty early. Essentially LRA doesn't seem to be cc0-aware in split_reg as ultimately inserted something between a cc0-setter and cc0-user. Oops. Yes, that is true. When I started to work on LRA, I decided to ignore cc0 first. But since then, no progress was made on this front. I guess the support of cc0 can be implemented for reasonable amount of time. It is just a priority issue. I still have a lot PRs for the targets already using LRA.
Re: [PATCH] Convert SPARC to LRA
On 09/29/2015 08:00 AM, Richard Biener wrote: On Tue, Sep 29, 2015 at 3:39 PM, Jeff Law wrote: On 09/29/2015 07:19 AM, Oleg Endo wrote: On Mon, 2015-09-28 at 15:28 -0500, Segher Boessenkool wrote: We can at least change the default to LRA, so new ports get it unless they like to hurt themselves. I don't think it makes sense to keep reload around *just* for the ports that are in "maintenance mode": by the time we are down to *just* those ports, it makes more sense to relabel them as "unmaintained". Just for my understanding ... what's the definition of "maintenance mode" or "unmaintained"? I'm not sure there's any formal definition. If the port isn't getting tested, bugs aren't getting fixed, fails to build, etc then it's probably a good bet you could put it into the unmaintained bucket. If the port does get occasional fixes (primarily driven by BZs), but not getting updated on a regular basis (such as conversion to LRA, conversion to RTL prologue/epilogue, etc), may be only getting occasional testing, etc. Then it's probably fair to call it in maintenance mode. A great example IMHO would be the m68k. Another criteria would be available hardware for which both the PA and alpha ports are a good example. When you can't buy new hardware then targets that could formerly host GCC quickly rot to the state where only cross-compilation is viable (and having "old" GCC is good enough). Very true. Actually the PA is the best example there. Alpha I believe has a functional-enough QEMU port to do real work and m68k has Aranym which I've used to bootstrap m68k within the last 18 months. Hell, I think Aranym actually ran faster than the last shipping real hardware! I'd say that all ports not in maintainance mode should be at least secondary archs as we can expect maintainers to be around to keep it at the quality level we expect for secondary targets. Now I'd like to do the opposite conclusion and declare all non-primary/secondary targets as in maintainance mode ... ;) We have 49 targets (counting directories) and 7 of them compose the list of primary and secondary triplets. I could live with that. jeff
Re: [PATCH] Convert SPARC to LRA
On Mon, 2015-09-28 at 15:28 -0500, Segher Boessenkool wrote:
> On Mon, Sep 28, 2015 at 03:23:37PM -0400, Vladimir Makarov wrote:
> > There are more ports using reload than LRA now. Even some major ports
> > (e.g. ppc64) did not switch to LRA.
>
> There still are some failures in the testsuite (ICEs even) so we're
> not there yet.
I've started to looking through the failures with a target of getting POWER
converted to LRA before the switch to stage3. From a quick scan, I see what
looks like two different ICEs on multiple tests and one wrong code gen issue.
The first ICE seems to be due to a conversion to long double and LRA ends
up going into a infinite loop spilling things until it hits a threshold and
quits with an ICE. I haven't spent enough time to determine whether this
is a LRA or port issue yet though. The simplest test case I have at the
moment is:
bergner@genoa:~/gcc/BUGS/LRA/20011123-1$ cat bug2.i
void
foo (long double *ldb1, double *db1)
{
*ldb1 = *db1;
}
bergner@genoa:~/gcc/BUGS/LRA/20011123-1$
/home/bergner/gcc/build/gcc-fsf-mainline-bootstrap-lra-default-debug/gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-mainline-bootstrap-lra-default-debug/gcc/ -S
-O1 -mvsx -S bug2.i
bug2.i: In function ‘foo’:
bug2.i:5:1: internal compiler error: Max. number of generated reload insns per
insn is achieved (90)
}
^
0x10962903 lra_constraints(bool)
/home/bergner/gcc/gcc-fsf-mainline-bootstrap-lra-default/gcc/lra-constraints.c:4351
0x10942af7 lra(_IO_FILE*)
/home/bergner/gcc/gcc-fsf-mainline-bootstrap-lra-default/gcc/lra.c:2298
0x108c0ac7 do_reload
/home/bergner/gcc/gcc-fsf-mainline-bootstrap-lra-default/gcc/ira.c:5391
0x108c1183 execute
/home/bergner/gcc/gcc-fsf-mainline-bootstrap-lra-default/gcc/ira.c:5562
After IRA, things are pretty simple, with just the following one insn which
needs
a reload/spill, since we don't have memory to memory ops on POWER:
(insn 7 4 10 2 (parallel [
(set (mem:TF (reg:DI 3 3 [ ldb1 ]) [0 *ldb1_5(D)+0 S16 A128])
(float_extend:TF (mem:DF (reg:DI 4 4 [ db1 ]) [0 *db1_2(D)+0 S8
A64])))
(use (const_double:DF 0.0 [0x0.0p+0]))
]) bug2.i:4 445 {*extenddftf2_internal}
(expr_list:REG_DEAD (reg:DI 4 4 [ db1 ])
(expr_list:REG_DEAD (reg:DI 3 3 [ ldb1 ])
(nil
In LRA, comes along and gives us the following which looks good:
(insn 7 4 11 2 (parallel [
(set (reg:TF 159)
(float_extend:TF (mem:DF (reg:DI 4 4 [ db1 ]) [0 *db1_2(D)+0 S8
A64])))
(use (const_double:DF 0.0 [0x0.0p+0]))
]) bug2.i:4 445 {*extenddftf2_internal}
(expr_list:REG_DEAD (reg:DI 4 4 [ db1 ])
(expr_list:REG_DEAD (reg:DI 3 3 [ ldb1 ])
(nil
(insn 11 7 10 2 (set (mem:TF (reg:DI 3 3 [ ldb1 ]) [0 *ldb1_5(D)+0 S16 A128])
(reg:TF 159)) bug2.i:4 435 {*movtf_64bit_dm}
(nil))
but for some reason, it thinks reg 159 needs reloading and gives us:
(insn 7 4 12 2 (parallel [
(set (reg:TF 159)
(float_extend:TF (mem:DF (reg:DI 4 4 [ db1 ]) [0 *db1_2(D)+0 S8
A64])))
(use (const_double:DF 0.0 [0x0.0p+0]))
]) bug2.i:4 445 {*extenddftf2_internal}
(expr_list:REG_DEAD (reg:DI 4 4 [ db1 ])
(expr_list:REG_DEAD (reg:DI 3 3 [ ldb1 ])
(nil
(insn 12 7 11 2 (set (reg:TF 160 [159])
(reg:TF 159)) bug2.i:4 435 {*movtf_64bit_dm}
(nil))
(insn 11 12 10 2 (set (mem:TF (reg:DI 3 3 [ ldb1 ]) [0 *ldb1_5(D)+0 S16 A128])
(reg:TF 160 [159])) bug2.i:4 435 {*movtf_64bit_dm}
(nil))
and we end up doing it again and again and...until we hit the reload threshold
and ICE. That's as far as I've gotten at this point. Comments welcome since
I've had to put this on the shelf at the moment while working on next year's
work schedule for our team.
I haven't had a chance to look into the other ICE or wrong code gen issue yet,
but will eventually will get to those.
Peter
Re: [PATCH] Convert SPARC to LRA
On Tue, Sep 29, 2015 at 3:39 PM, Jeff Law wrote: > On 09/29/2015 07:19 AM, Oleg Endo wrote: >> >> On Mon, 2015-09-28 at 15:28 -0500, Segher Boessenkool wrote: >> >>> We can at least change the default to LRA, so new ports get it unless >>> they like to hurt themselves. >>> >>> I don't think it makes sense to keep reload around *just* for the ports >>> that are in "maintenance mode": by the time we are down to *just* those >>> ports, it makes more sense to relabel them as "unmaintained". >> >> >> Just for my understanding ... what's the definition of "maintenance >> mode" or "unmaintained"? > > I'm not sure there's any formal definition. > > If the port isn't getting tested, bugs aren't getting fixed, fails to build, > etc then it's probably a good bet you could put it into the unmaintained > bucket. > > If the port does get occasional fixes (primarily driven by BZs), but not > getting updated on a regular basis (such as conversion to LRA, conversion to > RTL prologue/epilogue, etc), may be only getting occasional testing, etc. > Then it's probably fair to call it in maintenance mode. A great example > IMHO would be the m68k. Another criteria would be available hardware for which both the PA and alpha ports are a good example. When you can't buy new hardware then targets that could formerly host GCC quickly rot to the state where only cross-compilation is viable (and having "old" GCC is good enough). > I would say we probably have many ports in maintenance mode right now. Not > sure if any are in the unmaintained mode with perhaps the exception of > interix. I'd say that all ports not in maintainance mode should be at least secondary archs as we can expect maintainers to be around to keep it at the quality level we expect for secondary targets. Now I'd like to do the opposite conclusion and declare all non-primary/secondary targets as in maintainance mode ... ;) We have 49 targets (counting directories) and 7 of them compose the list of primary and secondary triplets. Richard. > jeff
Re: [PATCH] Convert SPARC to LRA
On 09/28/2015 02:28 PM, Segher Boessenkool wrote: On Mon, Sep 28, 2015 at 03:23:37PM -0400, Vladimir Makarov wrote: There are more ports using reload than LRA now. Even some major ports (e.g. ppc64) did not switch to LRA. There still are some failures in the testsuite (ICEs even) so we're not there yet. I usually say target maintainers, that if they don't switch LRA they probably will have problems with maintenance and development in a long perspective. New things are easier to implement in LRA. It is also true that new *ports* are easier to do with LRA than with reload :-) Right. And if we set the expectation that a new port must use LRA, then I think we're fine. We can at least change the default to LRA, so new ports get it unless they like to hurt themselves. I don't think it makes sense to keep reload around *just* for the ports that are in "maintenance mode": by the time we are down to *just* those ports, it makes more sense to relabel them as "unmaintained". FWIW, I tried to build a simple cc0 target with LRA (v850-elf), but it fell over pretty early. Essentially LRA doesn't seem to be cc0-aware in split_reg as ultimately inserted something between a cc0-setter and cc0-user. Oops. jeff
Re: [PATCH] Convert SPARC to LRA
On 09/29/2015 07:19 AM, Oleg Endo wrote: On Mon, 2015-09-28 at 15:28 -0500, Segher Boessenkool wrote: We can at least change the default to LRA, so new ports get it unless they like to hurt themselves. I don't think it makes sense to keep reload around *just* for the ports that are in "maintenance mode": by the time we are down to *just* those ports, it makes more sense to relabel them as "unmaintained". Just for my understanding ... what's the definition of "maintenance mode" or "unmaintained"? I'm not sure there's any formal definition. If the port isn't getting tested, bugs aren't getting fixed, fails to build, etc then it's probably a good bet you could put it into the unmaintained bucket. If the port does get occasional fixes (primarily driven by BZs), but not getting updated on a regular basis (such as conversion to LRA, conversion to RTL prologue/epilogue, etc), may be only getting occasional testing, etc. Then it's probably fair to call it in maintenance mode. A great example IMHO would be the m68k. I would say we probably have many ports in maintenance mode right now. Not sure if any are in the unmaintained mode with perhaps the exception of interix. jeff
Re: [PATCH] Convert SPARC to LRA
On Mon, 2015-09-28 at 15:28 -0500, Segher Boessenkool wrote: > We can at least change the default to LRA, so new ports get it unless > they like to hurt themselves. > > I don't think it makes sense to keep reload around *just* for the ports > that are in "maintenance mode": by the time we are down to *just* those > ports, it makes more sense to relabel them as "unmaintained". Just for my understanding ... what's the definition of "maintenance mode" or "unmaintained"? Cheers, Oleg
Re: [PATCH] Convert SPARC to LRA
On Mon, Sep 28, 2015 at 03:23:37PM -0400, Vladimir Makarov wrote: > There are more ports using reload than LRA now. Even some major ports > (e.g. ppc64) did not switch to LRA. There still are some failures in the testsuite (ICEs even) so we're not there yet. > I usually say target maintainers, that if they don't switch LRA they > probably will have problems with maintenance and development in a long > perspective. New things are easier to implement in LRA. It is also true that new *ports* are easier to do with LRA than with reload :-) > >It *may* be time to decree that any new ports must use the LRA path > >rather than reload. I'm still on the fence with that. > > That is probably a good policy I see now. Porting LRA might be not an > easy task as a lot of target hooks (and even insn definitions, e.g. > hints *?!) were written taking reload algorithms into account. LRA uses > different ones and many hook implementations are misleading. Many > target ports are just in a maintenance mode and simply there are no > resources to do LRA port for this targets. So I believe reload will > stay for a long time. We can at least change the default to LRA, so new ports get it unless they like to hurt themselves. I don't think it makes sense to keep reload around *just* for the ports that are in "maintenance mode": by the time we are down to *just* those ports, it makes more sense to relabel them as "unmaintained". Segher
Re: [PATCH] Convert SPARC to LRA
On 09/27/2015 09:29 PM, Jeff Law wrote: On 09/27/2015 01:57 PM, Hans-Peter Nilsson wrote: On Wed, 9 Sep 2015, Mike Stump wrote: On Sep 8, 2015, at 9:41 PM, David Miller wrote: +#define TARGET_LRA_P hook_bool_void_true Are we at the point there this should be the default, and old ports should just define to false, if they really need to? I think no. For one, we don't have proper target documentation updates for LRA. What does it need? What is outdated? Also, give ample time for gcc releases of odd ports with LRA to get into the public and cover most of the inevitable remaining bugs. Not even sh has moved over due to remaining issues. Let the reports come in - and be fixed. Let's revisit in a year or two. I don't think we're there yet either -- many ports still require some guidance from Vlad to get working with LRA. There are more ports using reload than LRA now. Even some major ports (e.g. ppc64) did not switch to LRA. I usually say target maintainers, that if they don't switch LRA they probably will have problems with maintenance and development in a long perspective. New things are easier to implement in LRA. Intel developers recognized this long ago and implemented some new optimizations in RA (the last biggest one was pic hard register reuse). According to them, it would be much harder to implement this in reload. On the other hand a lot of work was done in reload during long years to accommodate some unique target requirements as SH. A lot of efforts is needed to implement this in LRA to achieve the same performance as reload. It *may* be time to decree that any new ports must use the LRA path rather than reload. I'm still on the fence with that. That is probably a good policy I see now. Porting LRA might be not an easy task as a lot of target hooks (and even insn definitions, e.g. hints *?!) were written taking reload algorithms into account. LRA uses different ones and many hook implementations are misleading. Many target ports are just in a maintenance mode and simply there are no resources to do LRA port for this targets. So I believe reload will stay for a long time.
Re: [PATCH] Convert SPARC to LRA
From: Oleg Endo Date: Mon, 28 Sep 2015 21:26:14 +0900 > LRA on SH seems to work without GCC test suite failures. However, I'd > expect that there still hidden bugs not covered by the test suite. SH's > R0 spill failures are greatly reduced with LRA, although some hacks had > to be added to the SH backend to make it work at all. Despite that, we > see quite some significant code size increases compared to reload. If > the difference wasn't that big, we'd probably turn LRA on by default for > SH in GCC 6... One weakness I noticed while working on the sparc conversion is that the bootstrap of the compiler tests reload/LRA better than the testsuite does. Which is unfortunate, because bootstrap failures are significantly harder to analyze and debug than individual testsuite cases.
Re: [PATCH] Convert SPARC to LRA
On Sep 27, 2015, at 6:29 PM, Jeff Law wrote: > I don't think we're there yet either -- many ports still require some > guidance from Vlad to get working with LRA. > > It *may* be time to decree that any new ports must use the LRA path rather > than reload. I'm still on the fence with that. So, I think it makes sense to change the default for LRA to on now. Port maintainers for which this isn’t the right choice (sh, cause code size regressions), can then default it to off in the port. We can then use the #define LRA in the port as an indicator that things are not fine on that port and ideally LRA should be enhanced to make the port work better. When no port has a #define left, we can then safely rm -rf all the non-LRA code.
Re: [PATCH] Convert SPARC to LRA
On Sun, 2015-09-27 at 19:29 -0600, Jeff Law wrote: > On 09/27/2015 01:57 PM, Hans-Peter Nilsson wrote: > > On Wed, 9 Sep 2015, Mike Stump wrote: > > > >> On Sep 8, 2015, at 9:41 PM, David Miller wrote: > >>> +#define TARGET_LRA_P hook_bool_void_true > >> > >> Are we at the point there this should be the default, and old > >> ports should just define to false, if they really need to? > > > > I think no. For one, we don't have proper target documentation > > updates for LRA. What does it need? What is outdated? > > > > Also, give ample time for gcc releases of odd ports with LRA to > > get into the public and cover most of the inevitable remaining > > bugs. Not even sh has moved over due to remaining issues. Let > > the reports come in - and be fixed. Let's revisit in a year or > > two. > I don't think we're there yet either -- many ports still require some > guidance from Vlad to get working with LRA. > > It *may* be time to decree that any new ports must use the LRA path > rather than reload. I'm still on the fence with that. LRA on SH seems to work without GCC test suite failures. However, I'd expect that there still hidden bugs not covered by the test suite. SH's R0 spill failures are greatly reduced with LRA, although some hacks had to be added to the SH backend to make it work at all. Despite that, we see quite some significant code size increases compared to reload. If the difference wasn't that big, we'd probably turn LRA on by default for SH in GCC 6... Cheers, Oleg
Re: [PATCH] Convert SPARC to LRA
On 09/27/2015 01:57 PM, Hans-Peter Nilsson wrote: On Wed, 9 Sep 2015, Mike Stump wrote: On Sep 8, 2015, at 9:41 PM, David Miller wrote: +#define TARGET_LRA_P hook_bool_void_true Are we at the point there this should be the default, and old ports should just define to false, if they really need to? I think no. For one, we don't have proper target documentation updates for LRA. What does it need? What is outdated? Also, give ample time for gcc releases of odd ports with LRA to get into the public and cover most of the inevitable remaining bugs. Not even sh has moved over due to remaining issues. Let the reports come in - and be fixed. Let's revisit in a year or two. I don't think we're there yet either -- many ports still require some guidance from Vlad to get working with LRA. It *may* be time to decree that any new ports must use the LRA path rather than reload. I'm still on the fence with that. jeff
Re: [PATCH] Convert SPARC to LRA
On Wed, 9 Sep 2015, Mike Stump wrote: > On Sep 8, 2015, at 9:41 PM, David Miller wrote: > > +#define TARGET_LRA_P hook_bool_void_true > > Are we at the point there this should be the default, and old > ports should just define to false, if they really need to? I think no. For one, we don't have proper target documentation updates for LRA. What does it need? What is outdated? Also, give ample time for gcc releases of odd ports with LRA to get into the public and cover most of the inevitable remaining bugs. Not even sh has moved over due to remaining issues. Let the reports come in - and be fixed. Let's revisit in a year or two. brgds, H-P
Re: [PATCH] Convert SPARC to LRA
From: Eric Botcazou Date: Thu, 17 Sep 2015 23:13:21 +0200 > Did you keep the 64-bit promotion in PROMOTE_MODE or...? Yes I had to, the compiler aborts() if I make it use SImode on 64-bit. I'll take a closer look soon.
Re: [PATCH] Convert SPARC to LRA
> > You need to update https://gcc.gnu.org/backends.html > > Done. Nice work! Did you keep the 64-bit promotion in PROMOTE_MODE or...? -- Eric Botcazou
Re: [PATCH] Convert SPARC to LRA
From: Eric Botcazou Date: Sat, 12 Sep 2015 16:04:09 +0200 > You need to update https://gcc.gnu.org/backends.html Done.
Re: [PATCH] Convert SPARC to LRA
From: David Miller
Date: Mon, 14 Sep 2015 11:30:29 -0700 (PDT)
> There are some other issues I'm having troubles resolving for 64-bit
> native bootstraps as well, and I am probably going to revert the LRA
> sparc changes unless I can resolve them by the end of today.
So I was actually able to resolve these problems, and committed the
following patch.
The big take-aways are:
1) Since we can only access SFmode/SImode/etc. in FP_REGS but not
necessarily in EXTRA_FP_REGS, we have to tell LRA that secondary
memory is needed when moving such a mode between those two classes.
2) HARD_REGNO_CALLER_SAVE_MODE's default should really be reconsidered.
If the caller has an explicit mode in mind we should just use it
instead just going to choose_hard_reg_mode(). That causes stupid
things like using a DFmode register to spill an SFmode value and
all the subregging that results from that.
3) It's amazing how much we get away with in RELOAD, particular wrt.
to addressing. Here all of the "(set x (HIGH (SYMBOLIC...)))"
were always available even when flag_pic and this was never
noticed before.
[PATCH] Fix LRA regressions on 64-bit SPARC.
gcc/
* config/sparc/sparc-protos.h (sparc_secondary_memory_needed):
Declare.
* config/sparc/sparc.c (sparc_secondary_memory_needed): New
function.
* config/sparc/sparc.h (SECONDARY_MEMORY_NEEDED): Use it.
(HARD_REGNO_CALLER_SAVE_MODE): Define.
* config/sparc/sparc.md (sethi_di_medlow, losum_di_medlow, seth44)
(setm44, setl44, sethh, setlm, sethm, setlo, embmedany_sethi)
(embmedany_losum, embmedany_brsum, embmedany_textuhi)
(embmedany_texthi, embmedany_textulo, embmedany_textlo): Do not
provide when flag_pic.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@227847
138bc75d-0d04-0410-961f-82ee72b054a4
---
gcc/ChangeLog | 14 ++
gcc/config/sparc/sparc-protos.h | 2 ++
gcc/config/sparc/sparc.c| 20
gcc/config/sparc/sparc.h| 14 +-
gcc/config/sparc/sparc.md | 32
5 files changed, 61 insertions(+), 21 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 76566ca..42faf2e 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,17 @@
+2015-09-17 David S. Miller
+
+ * config/sparc/sparc-protos.h (sparc_secondary_memory_needed):
+ Declare.
+ * config/sparc/sparc.c (sparc_secondary_memory_needed): New
+ function.
+ * config/sparc/sparc.h (SECONDARY_MEMORY_NEEDED): Use it.
+ (HARD_REGNO_CALLER_SAVE_MODE): Define.
+ * config/sparc/sparc.md (sethi_di_medlow, losum_di_medlow, seth44)
+ (setm44, setl44, sethh, setlm, sethm, setlo, embmedany_sethi)
+ (embmedany_losum, embmedany_brsum, embmedany_textuhi)
+ (embmedany_texthi, embmedany_textulo, embmedany_textlo): Do not
+ provide when flag_pic.
+
2015-09-17 Kaz Kojima
* config/sh/sh.c (label_ref_list_d_pool): Adjust to
diff --git a/gcc/config/sparc/sparc-protos.h b/gcc/config/sparc/sparc-protos.h
index 1431437..18192fd 100644
--- a/gcc/config/sparc/sparc-protos.h
+++ b/gcc/config/sparc/sparc-protos.h
@@ -62,6 +62,8 @@ extern bool constant_address_p (rtx);
extern bool legitimate_pic_operand_p (rtx);
extern rtx sparc_legitimize_reload_address (rtx, machine_mode, int, int,
int, int *win);
+extern bool sparc_secondary_memory_needed (enum reg_class, enum reg_class,
+ machine_mode);
extern void load_got_register (void);
extern void sparc_emit_call_insn (rtx, rtx);
extern void sparc_defer_case_vector (rtx, rtx, int);
diff --git a/gcc/config/sparc/sparc.c b/gcc/config/sparc/sparc.c
index b41800c..f4ad68d 100644
--- a/gcc/config/sparc/sparc.c
+++ b/gcc/config/sparc/sparc.c
@@ -12283,6 +12283,26 @@ sparc_expand_vector_init (rtx target, rtx vals)
emit_move_insn (target, mem);
}
+bool sparc_secondary_memory_needed (enum reg_class class1, enum reg_class
class2,
+ machine_mode mode)
+{
+ if (FP_REG_CLASS_P (class1) != FP_REG_CLASS_P (class2))
+{
+ if (! TARGET_VIS3
+ || GET_MODE_SIZE (mode) > 8
+ || GET_MODE_SIZE (mode) < 4)
+ return true;
+ return false;
+}
+
+ if (GET_MODE_SIZE (mode) == 4
+ && ((class1 == FP_REGS && class2 == EXTRA_FP_REGS)
+ || (class1 == EXTRA_FP_REGS && class2 == FP_REGS)))
+return true;
+
+ return false;
+}
+
/* Implement TARGET_SECONDARY_RELOAD. */
static reg_class_t
diff --git a/gcc/config/sparc/sparc.h b/gcc/config/sparc/sparc.h
index 8343671..1f26232 100644
--- a/gcc/config/sparc/sparc.h
+++ b/gcc/config/sparc/sparc.h
@@ -747,6 +747,12 @@ extern int sparc_mode_class[];
register window instruction in the prologue. */
#define HARD_REGNO_RENAME_OK(FROM, TO) ((FROM) != 1)
+/* Select a register
Re: [PATCH] Convert SPARC to LRA
From: Richard Henderson Date: Mon, 14 Sep 2015 10:20:00 -0700 > There's a possibility of benefit though -- br and movr only work with DImode. > You may want to examine the generated code to decide one way or another. > > It's possible that the extra comparison instructions don't really matter > compared with the larger spill slot, but you never know... And another issue is that I get expr.c:expand_expr_real_1() assertion failures when I try to use SImode for 64-bit, specifically the one in this code sequence: /* Get the signedness to be used for this variable. Ensure we get the same mode we got when the variable was declared. */ if (code != SSA_NAME) pmode = promote_decl_mode (exp, &unsignedp); else if ((g = SSA_NAME_DEF_STMT (ssa_name)) && gimple_code (g) == GIMPLE_CALL && !gimple_call_internal_p (g)) pmode = promote_function_mode (type, mode, &unsignedp, gimple_call_fntype (g), 2); else pmode = promote_ssa_mode (ssa_name, &unsignedp); gcc_assert (GET_MODE (decl_rtl) == pmode); There are some other issues I'm having troubles resolving for 64-bit native bootstraps as well, and I am probably going to revert the LRA sparc changes unless I can resolve them by the end of today.
Re: [PATCH] Convert SPARC to LRA
On 09/12/2015 10:44 PM, David Miller wrote: > From: Eric Botcazou > Date: Sat, 12 Sep 2015 16:04:09 +0200 > >>> Richard, Eric, any objections? >> >> Do we really need to promote to 64-bit if TARGET_ARCH64? Most 32-bit >> instructions are still available. Otherwise this looks good to me. > > No, we don't, we can just promote to 32-bit. I'll make that adjustment > and update the backends page as well. There's a possibility of benefit though -- br and movr only work with DImode. You may want to examine the generated code to decide one way or another. It's possible that the extra comparison instructions don't really matter compared with the larger spill slot, but you never know... r~
Re: [PATCH] Convert SPARC to LRA
From: Eric Botcazou Date: Sat, 12 Sep 2015 16:04:09 +0200 >> Richard, Eric, any objections? > > Do we really need to promote to 64-bit if TARGET_ARCH64? Most 32-bit > instructions are still available. Otherwise this looks good to me. No, we don't, we can just promote to 32-bit. I'll make that adjustment and update the backends page as well. Thanks.
Re: [PATCH] Convert SPARC to LRA
> Richard, Eric, any objections? Do we really need to promote to 64-bit if TARGET_ARCH64? Most 32-bit instructions are still available. Otherwise this looks good to me. You need to update https://gcc.gnu.org/backends.html -- Eric Botcazou
Re: [PATCH] Convert SPARC to LRA
On 09/11/2015 12:43 PM, David Miller wrote: > From: David Miller > Date: Tue, 08 Sep 2015 21:41:15 -0700 (PDT) > >> I'm therefore reasonably confident in these changes, but I will >> not apply them just yet to give the other sparc maintainers some >> time to review and give feedback. > > Richard, Eric, any objections? > Nope. r~
Re: [PATCH] Convert SPARC to LRA
From: David Miller Date: Tue, 08 Sep 2015 21:41:15 -0700 (PDT) > I'm therefore reasonably confident in these changes, but I will > not apply them just yet to give the other sparc maintainers some > time to review and give feedback. Richard, Eric, any objections?
Re: [PATCH] Convert SPARC to LRA
On Sep 8, 2015, at 9:41 PM, David Miller wrote: > +#define TARGET_LRA_P hook_bool_void_true Are we at the point there this should be the default, and old ports should just define to false, if they really need to? I’m using nothing but LRA as well.
