| Message ID | 20150908.214115.1585933992134500164.davem@davemloft.net |
|---|---|
| State | New |
| Headers | show |
On Sep 8, 2015, at 9:41 PM, David Miller <davem@davemloft.net> 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.
From: David Miller <davem@davemloft.net> 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?
On 09/11/2015 12:43 PM, David Miller wrote: > From: David Miller <davem@davemloft.net> > 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~
> 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
From: Eric Botcazou <ebotcazou@adacore.com> 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.
On 09/12/2015 10:44 PM, David Miller wrote: > From: Eric Botcazou <ebotcazou@adacore.com> > 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~
From: Richard Henderson <rth@redhat.com> 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.
From: Eric Botcazou <ebotcazou@adacore.com> Date: Sat, 12 Sep 2015 16:04:09 +0200 > You need to update https://gcc.gnu.org/backends.html Done.
> > You need to update https://gcc.gnu.org/backends.html > > Done. Nice work! Did you keep the 64-bit promotion in PROMOTE_MODE or...?
From: Eric Botcazou <ebotcazou@adacore.com> 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.
On Wed, 9 Sep 2015, Mike Stump wrote: > On Sep 8, 2015, at 9:41 PM, David Miller <davem@davemloft.net> 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
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 <davem@davemloft.net> 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
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 <davem@davemloft.net> 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
On Sep 27, 2015, at 6:29 PM, Jeff Law <law@redhat.com> 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.
From: Oleg Endo <oleg.endo@t-online.de> 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.
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 <davem@davemloft.net> 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.
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
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
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
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
On Tue, Sep 29, 2015 at 3:39 PM, Jeff Law <law@redhat.com> 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
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
On 09/29/2015 08:00 AM, Richard Biener wrote: > On Tue, Sep 29, 2015 at 3:39 PM, Jeff Law <law@redhat.com> 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
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.
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
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
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
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
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
Hello David, since the LRA patch is still reverted on the trunk, I guess the switch to LRA will not happen in GCC 6?
From: Sebastian Huber <sebastian.huber@embedded-brains.de> 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.
On 08/12/15 17:55, David Miller wrote: > From: Sebastian Huber <sebastian.huber@embedded-brains.de> > 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?
> 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.
diff --git a/gcc/config/sparc/constraints.md b/gcc/config/sparc/constraints.md index e12efa1..7a18879 100644 --- a/gcc/config/sparc/constraints.md +++ b/gcc/config/sparc/constraints.md @@ -44,6 +44,8 @@ (define_register_constraint "h" "(TARGET_V9 && TARGET_V8PLUS ? I64_REGS : NO_REGS)" "64-bit global or out register in V8+ mode") +(define_register_constraint "U" "(TARGET_ARCH32 ? GENERAL_REGS : NO_REGS)") + ;; Floating-point constant constraints (define_constraint "G" @@ -135,51 +137,6 @@ (match_code "mem") (match_test "memory_ok_for_ldd (op)"))) -;; This awkward register constraint is necessary because it is not -;; possible to express the "must be even numbered register" condition -;; using register classes. The problem is that membership in a -;; register class requires that all registers of a multi-regno -;; register be included in the set. It is add_to_hard_reg_set -;; and in_hard_reg_set_p which populate and test regsets with these -;; semantics. -;; -;; So this means that we would have to put both the even and odd -;; register into the register class, which would not restrict things -;; at all. -;; -;; Using a combination of GENERAL_REGS and HARD_REGNO_MODE_OK is not a -;; full solution either. In fact, even though IRA uses the macro -;; HARD_REGNO_MODE_OK to calculate which registers are prohibited from -;; use in certain modes, it still can allocate an odd hard register -;; for DImode values. This is due to how IRA populates the table -;; ira_useful_class_mode_regs[][]. It suffers from the same problem -;; as using a register class to describe this restriction. Namely, it -;; sets both the odd and even part of an even register pair in the -;; regset. Therefore IRA can and will allocate odd registers for -;; DImode values on 32-bit. -;; -;; There are legitimate cases where DImode values can end up in odd -;; hard registers, the most notable example is argument passing. -;; -;; What saves us is reload and the DImode splitters. Both are -;; necessary. The odd register splitters cannot match if, for -;; example, we have a non-offsetable MEM. Reload will notice this -;; case and reload the address into a single hard register. -;; -;; The real downfall of this awkward register constraint is that it does -;; not evaluate to a true register class like a bonafide use of -;; define_register_constraint would. This currently means that we cannot -;; use LRA on Sparc, since the constraint processing of LRA really depends -;; upon whether an extra constraint is for registers or not. It uses -;; reg_class_for_constraint, and checks it against NO_REGS. -(define_constraint "U" - "Pseudo-register or hard even-numbered integer register" - (and (match_test "TARGET_ARCH32") - (match_code "reg") - (ior (match_test "REGNO (op) < FIRST_PSEUDO_REGISTER") - (not (match_test "reload_in_progress && reg_renumber [REGNO (op)] < 0"))) - (match_test "register_ok_for_ldd (op)"))) - ;; Equivalent to 'T' but available in 64-bit mode (define_memory_constraint "W" "Memory reference for 'e' constraint floating-point register" diff --git a/gcc/config/sparc/sparc.c b/gcc/config/sparc/sparc.c index ed8a166..b41800c 100644 --- a/gcc/config/sparc/sparc.c +++ b/gcc/config/sparc/sparc.c @@ -808,6 +808,9 @@ char sparc_hard_reg_printed[8]; #undef TARGET_CAN_ELIMINATE #define TARGET_CAN_ELIMINATE sparc_can_eliminate +#undef TARGET_LRA_P +#define TARGET_LRA_P hook_bool_void_true + #undef TARGET_PREFERRED_RELOAD_CLASS #define TARGET_PREFERRED_RELOAD_CLASS sparc_preferred_reload_class @@ -4691,7 +4694,7 @@ enum sparc_mode_class { ((1 << (int) H_MODE) | (1 << (int) S_MODE) | (1 << (int) SF_MODE)) /* Modes for double-word and smaller quantities. */ -#define D_MODES (S_MODES | (1 << (int) D_MODE) | (1 << DF_MODE)) +#define D_MODES (S_MODES | (1 << (int) D_MODE) | (1 << (int) DF_MODE)) /* Modes for quad-word and smaller quantities. */ #define T_MODES (D_MODES | (1 << (int) T_MODE) | (1 << (int) TF_MODE)) @@ -4703,22 +4706,24 @@ enum sparc_mode_class { #define SF_MODES ((1 << (int) S_MODE) | (1 << (int) SF_MODE)) /* Modes for double-float and smaller quantities. */ -#define DF_MODES (SF_MODES | (1 << (int) D_MODE) | (1 << DF_MODE)) +#define DF_MODES (SF_MODES | (1 << (int) D_MODE) | (1 << (int) DF_MODE)) /* Modes for quad-float and smaller quantities. */ -#define TF_MODES (DF_MODES | (1 << (int) TF_MODE)) +#define TF_MODES (DF_MODES | (1 << (int) T_MODE) | (1 << (int) TF_MODE)) /* Modes for quad-float pairs and smaller quantities. */ -#define OF_MODES (TF_MODES | (1 << (int) OF_MODE)) +#define OF_MODES (TF_MODES | (1 << (int) O_MODE) | (1 << (int) OF_MODE)) /* Modes for double-float only quantities. */ #define DF_MODES_NO_S ((1 << (int) D_MODE) | (1 << (int) DF_MODE)) /* Modes for quad-float and double-float only quantities. */ -#define TF_MODES_NO_S (DF_MODES_NO_S | (1 << (int) TF_MODE)) +#define TF_MODES_NO_S \ + (DF_MODES_NO_S | (1 << (int) T_MODE) | (1 << (int) TF_MODE)) /* Modes for quad-float pairs and double-float only quantities. */ -#define OF_MODES_NO_S (TF_MODES_NO_S | (1 << (int) OF_MODE)) +#define OF_MODES_NO_S \ + (TF_MODES_NO_S | (1 << (int) O_MODE) | (1 << (int) OF_MODE)) /* Modes for condition codes. */ #define CC_MODES (1 << (int) CC_MODE) @@ -11188,7 +11193,7 @@ sparc_register_move_cost (machine_mode mode ATTRIBUTE_UNUSED, || sparc_cpu == PROCESSOR_NIAGARA2 || sparc_cpu == PROCESSOR_NIAGARA3 || sparc_cpu == PROCESSOR_NIAGARA4) - return 12; + return 8; return 6; } diff --git a/gcc/config/sparc/sparc.h b/gcc/config/sparc/sparc.h index 2cbe0d9..8343671 100644 --- a/gcc/config/sparc/sparc.h +++ b/gcc/config/sparc/sparc.h @@ -452,6 +452,17 @@ extern enum cmodel sparc_cmodel; /* target machine storage layout */ +/* Define this macro if it is advisable to hold scalars in registers + in a wider mode than that declared by the program. In such cases, + the value is constrained to be within the bounds of the declared + type, but kept valid in the wider mode. The signedness of the + extension may differ from that of the type. */ + +#define PROMOTE_MODE(MODE,UNSIGNEDP,TYPE) \ + if (GET_MODE_CLASS (MODE) == MODE_INT \ + && GET_MODE_SIZE (MODE) < (TARGET_ARCH64 ? 8 : 4)) \ + (MODE) = TARGET_ARCH64 ? DImode : SImode; + /* Define this if most significant bit is lowest numbered in instructions that operate on numbered bit-fields. */ #define BITS_BIG_ENDIAN 1 diff --git a/gcc/config/sparc/sparc.md b/gcc/config/sparc/sparc.md index 5b9f051..f514d9f 100644 --- a/gcc/config/sparc/sparc.md +++ b/gcc/config/sparc/sparc.md @@ -1467,13 +1467,13 @@ [(set (match_operand:SI 0 "register_operand" "=r") (lo_sum:SI (match_operand:SI 1 "register_operand" "r") (match_operand:SI 2 "immediate_operand" "in")))] - "" + "! flag_pic" "or\t%1, %%lo(%a2), %0") (define_insn "*movsi_high" [(set (match_operand:SI 0 "register_operand" "=r") (high:SI (match_operand:SI 1 "immediate_operand" "in")))] - "" + "! flag_pic" "sethi\t%%hi(%a1), %0") ;; The next two patterns must wrap the SYMBOL_REF in an UNSPEC