| Message ID | 20241015090835.3477629-1-glaubitz@physik.fu-berlin.de |
|---|---|
| State | New |
| Headers | show |
| Series | [v2] alpha: Add -mlra option | expand |
On Tue, Oct 15, 2024 at 11:09 AM John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote: > > PR target/66207 > * config/alpha/alpha.opt (mlra): New target option. > * config/alpha/alpha.cc (alpha_use_lra_p): New function. > (TARGET_LRA_P): Use it. > * config/alpha/alpha.opt.urls: Regenerate. IMO, we should simply deprecate non-BWX targets. If reload is going away, then there is no way for non-BWX targets to access reload internals they require for compilation. As mentioned in the PR, non-BWX targets are removed from distros anyway, so I guess there is no point to invest much time to modernize them, Uros. > > Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> > --- > gcc/config/alpha/alpha.cc | 10 +++++++++- > gcc/config/alpha/alpha.opt | 5 +++++ > gcc/config/alpha/alpha.opt.urls | 2 ++ > 3 files changed, 16 insertions(+), 1 deletion(-) > > v2: > - Rephrase patch short summary > > diff --git a/gcc/config/alpha/alpha.cc b/gcc/config/alpha/alpha.cc > index 74631a41693..218c66b6090 100644 > --- a/gcc/config/alpha/alpha.cc > +++ b/gcc/config/alpha/alpha.cc > @@ -9941,6 +9941,14 @@ alpha_c_mode_for_floating_type (enum tree_index ti) > return default_mode_for_floating_type (ti); > } > > +/* Implement TARGET_LRA_P. */ > + > +static bool > +alpha_use_lra_p () > +{ > + return alpha_lra_p; > +} > + > /* Initialize the GCC target structure. */ > #if TARGET_ABI_OPEN_VMS > # undef TARGET_ATTRIBUTE_TABLE > @@ -10124,7 +10132,7 @@ alpha_c_mode_for_floating_type (enum tree_index ti) > #endif > > #undef TARGET_LRA_P > -#define TARGET_LRA_P hook_bool_void_false > +#define TARGET_LRA_P alpha_use_lra_p > > #undef TARGET_LEGITIMATE_ADDRESS_P > #define TARGET_LEGITIMATE_ADDRESS_P alpha_legitimate_address_p > diff --git a/gcc/config/alpha/alpha.opt b/gcc/config/alpha/alpha.opt > index 62543d2689c..a4d6d58724a 100644 > --- a/gcc/config/alpha/alpha.opt > +++ b/gcc/config/alpha/alpha.opt > @@ -89,6 +89,11 @@ mlarge-text > Target RejectNegative InverseMask(SMALL_TEXT) > Emit indirect branches to local functions. > > +mlra > +Target Var(alpha_lra_p) Undocumented > +Usa LRA for reload instead of the old reload framework. This option is > +experimental, and it may be removed in future versions of the compiler. > + > mtls-kernel > Target Mask(TLS_KERNEL) > Emit rdval instead of rduniq for thread pointer. > diff --git a/gcc/config/alpha/alpha.opt.urls b/gcc/config/alpha/alpha.opt.urls > index a55c08328c3..916a3013f63 100644 > --- a/gcc/config/alpha/alpha.opt.urls > +++ b/gcc/config/alpha/alpha.opt.urls > @@ -44,6 +44,8 @@ UrlSuffix(gcc/DEC-Alpha-Options.html#index-msmall-data) > mlarge-data > UrlSuffix(gcc/DEC-Alpha-Options.html#index-mlarge-data) > > +; skipping UrlSuffix for 'mlra' due to finding no URLs > + > msmall-text > UrlSuffix(gcc/DEC-Alpha-Options.html#index-msmall-text) > > -- > 2.39.5 >
CC'ing Maciej who has also worked on Alpha Hi Uros, On Tue, 2024-10-15 at 12:29 +0200, Uros Bizjak wrote: > On Tue, Oct 15, 2024 at 11:09 AM John Paul Adrian Glaubitz > <glaubitz@physik.fu-berlin.de> wrote: > > > > PR target/66207 > > * config/alpha/alpha.opt (mlra): New target option. > > * config/alpha/alpha.cc (alpha_use_lra_p): New function. > > (TARGET_LRA_P): Use it. > > * config/alpha/alpha.opt.urls: Regenerate. > > IMO, we should simply deprecate non-BWX targets. If reload is going > away, then there is no way for non-BWX targets to access reload > internals they require for compilation. As mentioned in the PR, > non-BWX targets are removed from distros anyway, so I guess there is > no point to invest much time to modernize them, While Debian dropped support for non-BWX targets, NetBSD still supports them, from what I know. On Gentoo, users can actually configure the target baseline themselves. Adrian
On Tue, 15 Oct 2024, Uros Bizjak wrote: > > PR target/66207 > > * config/alpha/alpha.opt (mlra): New target option. > > * config/alpha/alpha.cc (alpha_use_lra_p): New function. > > (TARGET_LRA_P): Use it. > > * config/alpha/alpha.opt.urls: Regenerate. > > IMO, we should simply deprecate non-BWX targets. If reload is going > away, then there is no way for non-BWX targets to access reload > internals they require for compilation. As mentioned in the PR, > non-BWX targets are removed from distros anyway, so I guess there is > no point to invest much time to modernize them, Well, I have a lasting desire to keep non-BWX Alphas running, under Linux in particular, and I'm going to look into any issues around it; reload vs LRA is all software, so things can always be sorted one way or another. While I've been distracted by other matters lately, such as hardware failures that had to be dealt with urgently, this is now my priority #1 and I do hope to have at least some critical initial stuff in with this release cycle (noting that only ~5 weeks have left). NB I spoke to Richard about it while at LPC 2024 recently. Maciej
Hi Maciej, On Tue, 2024-10-15 at 13:36 +0100, Maciej W. Rozycki wrote: > > IMO, we should simply deprecate non-BWX targets. If reload is going > > away, then there is no way for non-BWX targets to access reload > > internals they require for compilation. As mentioned in the PR, > > non-BWX targets are removed from distros anyway, so I guess there is > > no point to invest much time to modernize them, > > Well, I have a lasting desire to keep non-BWX Alphas running, under Linux > in particular, and I'm going to look into any issues around it; reload vs > LRA is all software, so things can always be sorted one way or another. > > While I've been distracted by other matters lately, such as hardware > failures that had to be dealt with urgently, this is now my priority #1 > and I do hope to have at least some critical initial stuff in with this > release cycle (noting that only ~5 weeks have left). That's great. While I'm not really an expert for compiler development, I have beefy hardware available for GCC and kernel build tests, so if you have any patches for testing, please let me know. > NB I spoke to Richard about it while at LPC 2024 recently. OK, good. FWIW, it *seems* that LRA seems to just work with EV56 as the baseline and the following replacements in the code: s/reload_in_progress/reload_in_progress || lra_in_progress/g Adrian
On Tue, Oct 15, 2024 at 2:41 PM John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote: > > Hi Maciej, > > On Tue, 2024-10-15 at 13:36 +0100, Maciej W. Rozycki wrote: > > > IMO, we should simply deprecate non-BWX targets. If reload is going > > > away, then there is no way for non-BWX targets to access reload > > > internals they require for compilation. As mentioned in the PR, > > > non-BWX targets are removed from distros anyway, so I guess there is > > > no point to invest much time to modernize them, > > > > Well, I have a lasting desire to keep non-BWX Alphas running, under Linux > > in particular, and I'm going to look into any issues around it; reload vs > > LRA is all software, so things can always be sorted one way or another. > > > > While I've been distracted by other matters lately, such as hardware > > failures that had to be dealt with urgently, this is now my priority #1 > > and I do hope to have at least some critical initial stuff in with this > > release cycle (noting that only ~5 weeks have left). > > That's great. > > While I'm not really an expert for compiler development, I have beefy hardware > available for GCC and kernel build tests, so if you have any patches for testing, > please let me know. > > > NB I spoke to Richard about it while at LPC 2024 recently. > > OK, good. > > FWIW, it *seems* that LRA seems to just work with EV56 as the baseline and the > following replacements in the code: > > s/reload_in_progress/reload_in_progress || lra_in_progress/g If you can provide -mlra vs. -mno-lra testsuite results as well that would be interesting. Does "just work" mean you can build the compiler and its target libraries? In this case I would suggest to go further and pull the trigger now, defaulting to LRA but allowing to switch back to reload for testing. This is so the few people testing alpha at all can increase testing coverage - I don't think anybody runs older than EV5 HW. Is VMS on alpha still a thing btw? I still see it mentioned in config.gcc Richard. > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer > `. `' Physicist > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Hi Richard, On Tue, 2024-10-15 at 14:47 +0200, Richard Biener wrote: > If you can provide -mlra vs. -mno-lra testsuite results as well that > would be interesting. OK, I'll try to provide these. > Does "just work" mean you can build the compiler and its target > libraries? I'm performing a full native bootstrap build with all languages except D, Go and Rust enabled. This failed with an ICE with the default baseline at some point, but continues to build for a while now with --with-cpu=ev56. > In this case I would suggest to go further and pull the trigger now, > defaulting to LRA but allowing to switch back to reload for testing. > This is so the few people testing alpha at all can increase testing > coverage - I don't think anybody runs older than EV5 HW. Well, BWX requires EV56, not EV5. > Is VMS on alpha still a thing btw? I still see it mentioned in config.gcc OpenVMS on Alpha seems to be still supported by HP [1]. Whether they're using the latest version of GCC, is a different question through. Adrian > [1] https://h41379.www4.hpe.com/openvms/openvms_supportchart.html
On Tue, 2024-10-15 at 15:06 +0200, John Paul Adrian Glaubitz wrote: > On Tue, 2024-10-15 at 14:47 +0200, Richard Biener wrote: > > If you can provide -mlra vs. -mno-lra testsuite results as well that > > would be interesting. > > OK, I'll try to provide these. > > > Does "just work" mean you can build the compiler and its target > > libraries? > > I'm performing a full native bootstrap build with all languages except D, > Go and Rust enabled. This failed with an ICE with the default baseline > at some point, but continues to build for a while now with --with-cpu=ev56. Bootstrap catches only some issues, not all. E.g. see current SH LRA status (bootstrap OK, still produces silent wrong-code and other issues). Hence the request to also run the testsuite (make -k check) and diff the .sum files. Best regards, Oleg Endo
On Tue, 15 Oct 2024, Richard Biener wrote: > > FWIW, it *seems* that LRA seems to just work with EV56 as the baseline and the > > following replacements in the code: > > > > s/reload_in_progress/reload_in_progress || lra_in_progress/g > > If you can provide -mlra vs. -mno-lra testsuite results as well that > would be interesting. > > Does "just work" mean you can build the compiler and its target > libraries? In this case > I would suggest to go further and pull the trigger now, defaulting to > LRA but allowing > to switch back to reload for testing. This is so the few people > testing alpha at all can > increase testing coverage - I don't think anybody runs older than EV5 HW. Well, I did run EV4 testing with real hardware recently. As an example here's the summary of results for the C frontend only: === gcc Summary === # of expected passes 149119 # of unexpected failures 134 # of expected failures 1117 # of unresolved testcases 3 # of unsupported tests 3176 (I ran testing across the board). If non-BWX is known to be broken with LRA, then perhaps let's only make the switch for BWX for the time being? Maciej
On 10/15/24 6:47 AM, Richard Biener wrote: > On Tue, Oct 15, 2024 at 2:41 PM John Paul Adrian Glaubitz > <glaubitz@physik.fu-berlin.de> wrote: >> >> Hi Maciej, >> >> On Tue, 2024-10-15 at 13:36 +0100, Maciej W. Rozycki wrote: >>>> IMO, we should simply deprecate non-BWX targets. If reload is going >>>> away, then there is no way for non-BWX targets to access reload >>>> internals they require for compilation. As mentioned in the PR, >>>> non-BWX targets are removed from distros anyway, so I guess there is >>>> no point to invest much time to modernize them, >>> >>> Well, I have a lasting desire to keep non-BWX Alphas running, under Linux >>> in particular, and I'm going to look into any issues around it; reload vs >>> LRA is all software, so things can always be sorted one way or another. >>> >>> While I've been distracted by other matters lately, such as hardware >>> failures that had to be dealt with urgently, this is now my priority #1 >>> and I do hope to have at least some critical initial stuff in with this >>> release cycle (noting that only ~5 weeks have left). >> >> That's great. >> >> While I'm not really an expert for compiler development, I have beefy hardware >> available for GCC and kernel build tests, so if you have any patches for testing, >> please let me know. >> >>> NB I spoke to Richard about it while at LPC 2024 recently. >> >> OK, good. >> >> FWIW, it *seems* that LRA seems to just work with EV56 as the baseline and the >> following replacements in the code: >> >> s/reload_in_progress/reload_in_progress || lra_in_progress/g > > If you can provide -mlra vs. -mno-lra testsuite results as well that > would be interesting. > > Does "just work" mean you can build the compiler and its target > libraries? In this case > I would suggest to go further and pull the trigger now, defaulting to > LRA but allowing > to switch back to reload for testing. This is so the few people > testing alpha at all can > increase testing coverage - I don't think anybody runs older than EV5 HW. > > Is VMS on alpha still a thing btw? I still see it mentioned in config.gcc Also note if we think it's basically working I can flip my tester to default to LRA. It bootstraps and regtests alpha once a week via qemu. I think it's testing the baseline configuration, so presumably non-BWX variants. That can probably be adjusted if necessary. Jeff
On Tue, 2024-10-15 at 07:56 -0600, Jeff Law wrote: > Also note if we think it's basically working I can flip my tester to > default to LRA. It bootstraps and regtests alpha once a week via qemu. > > I think it's testing the baseline configuration, so presumably non-BWX > variants. That can probably be adjusted if necessary. It does seem to fail when enabling M2 though: m2/pge -k -l ../../gcc/m2/gm2-compiler/P2Build.bnf -o m2/gm2-compiler-boot/P2Build.mod m2/pge -k -l ../../gcc/m2/gm2-compiler/P3Build.bnf -o m2/gm2-compiler-boot/P3Build.mod m2/pge -k -l ../../gcc/m2/gm2-compiler/PHBuild.bnf -o m2/gm2-compiler-boot/PHBuild.mod m2/pge -k -l ../../gcc/m2/gm2-compiler/PCBuild.bnf -o m2/gm2-compiler-boot/PCBuild.mod m2/pge -k -l ../../gcc/m2/gm2-compiler/P1Build.bnf -o m2/gm2-compiler-boot/P1Build.mod m2/pge -k -l ../../gcc/m2/gm2-compiler/P0SyntaxCheck.bnf -o m2/gm2-compiler-boot/P0SyntaxCheck.mod terminate called after throwing an instance of 'unsigned int' make[3]: *** [../../gcc/m2/Make-lang.in:1778: m2/gm2-compiler-boot/P2Build.mod] Aborted make[3]: *** Deleting file 'm2/gm2-compiler-boot/P2Build.mod' make[3]: *** Waiting for unfinished jobs.... terminate called after throwing an instance of 'unsigned int' make[3]: *** [../../gcc/m2/Make-lang.in:1778: m2/gm2-compiler-boot/P0SyntaxCheck.mod] Aborted make[3]: *** Deleting file 'm2/gm2-compiler-boot/P0SyntaxCheck.mod' terminate called after throwing an instance of 'unsigned int' make[3]: *** [../../gcc/m2/Make-lang.in:1778: m2/gm2-compiler-boot/P1Build.mod] Aborted make[3]: *** Deleting file 'm2/gm2-compiler-boot/P1Build.mod' terminate called after throwing an instance of 'unsigned int' make[3]: *** [../../gcc/m2/Make-lang.in:1778: m2/gm2-compiler-boot/P3Build.mod] Aborted make[3]: *** Deleting file 'm2/gm2-compiler-boot/P3Build.mod' terminate called after throwing an instance of 'unsigned int' make[3]: *** [../../gcc/m2/Make-lang.in:1778: m2/gm2-compiler-boot/PHBuild.mod] Aborted make[3]: *** Deleting file 'm2/gm2-compiler-boot/PHBuild.mod' terminate called after throwing an instance of 'unsigned int' make[3]: *** [../../gcc/m2/Make-lang.in:1778: m2/gm2-compiler-boot/PCBuild.mod] Aborted make[3]: *** Deleting file 'm2/gm2-compiler-boot/PCBuild.mod' Adrian
On Tue, 2024-10-15 at 16:18 +0200, John Paul Adrian Glaubitz wrote: > On Tue, 2024-10-15 at 07:56 -0600, Jeff Law wrote: > > Also note if we think it's basically working I can flip my tester to > > default to LRA. It bootstraps and regtests alpha once a week via qemu. > > > > I think it's testing the baseline configuration, so presumably non-BWX > > variants. That can probably be adjusted if necessary. > > It does seem to fail when enabling M2 though: > > m2/pge -k -l ../../gcc/m2/gm2-compiler/P2Build.bnf -o m2/gm2-compiler-boot/P2Build.mod > m2/pge -k -l ../../gcc/m2/gm2-compiler/P3Build.bnf -o m2/gm2-compiler-boot/P3Build.mod > m2/pge -k -l ../../gcc/m2/gm2-compiler/PHBuild.bnf -o m2/gm2-compiler-boot/PHBuild.mod > m2/pge -k -l ../../gcc/m2/gm2-compiler/PCBuild.bnf -o m2/gm2-compiler-boot/PCBuild.mod > m2/pge -k -l ../../gcc/m2/gm2-compiler/P1Build.bnf -o m2/gm2-compiler-boot/P1Build.mod > m2/pge -k -l ../../gcc/m2/gm2-compiler/P0SyntaxCheck.bnf -o m2/gm2-compiler-boot/P0SyntaxCheck.mod > terminate called after throwing an instance of 'unsigned int' > make[3]: *** [../../gcc/m2/Make-lang.in:1778: m2/gm2-compiler-boot/P2Build.mod] Aborted > make[3]: *** Deleting file 'm2/gm2-compiler-boot/P2Build.mod' > make[3]: *** Waiting for unfinished jobs.... > terminate called after throwing an instance of 'unsigned int' > make[3]: *** [../../gcc/m2/Make-lang.in:1778: m2/gm2-compiler-boot/P0SyntaxCheck.mod] Aborted > make[3]: *** Deleting file 'm2/gm2-compiler-boot/P0SyntaxCheck.mod' > terminate called after throwing an instance of 'unsigned int' > make[3]: *** [../../gcc/m2/Make-lang.in:1778: m2/gm2-compiler-boot/P1Build.mod] Aborted > make[3]: *** Deleting file 'm2/gm2-compiler-boot/P1Build.mod' > terminate called after throwing an instance of 'unsigned int' > make[3]: *** [../../gcc/m2/Make-lang.in:1778: m2/gm2-compiler-boot/P3Build.mod] Aborted > make[3]: *** Deleting file 'm2/gm2-compiler-boot/P3Build.mod' > terminate called after throwing an instance of 'unsigned int' > make[3]: *** [../../gcc/m2/Make-lang.in:1778: m2/gm2-compiler-boot/PHBuild.mod] Aborted > make[3]: *** Deleting file 'm2/gm2-compiler-boot/PHBuild.mod' > terminate called after throwing an instance of 'unsigned int' > make[3]: *** [../../gcc/m2/Make-lang.in:1778: m2/gm2-compiler-boot/PCBuild.mod] Aborted > make[3]: *** Deleting file 'm2/gm2-compiler-boot/PCBuild.mod' Disabling M2 is enough to fix this. Thus, GCC bootstraps fine with LRA if one disables M2 and uses EV56 as the baseline. I will run the testsuite now for both Reload and LRA. Adrian
On Wed, Oct 16, 2024 at 4:40 AM John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote: > > On Tue, 2024-10-15 at 16:18 +0200, John Paul Adrian Glaubitz wrote: > > On Tue, 2024-10-15 at 07:56 -0600, Jeff Law wrote: > > > Also note if we think it's basically working I can flip my tester to > > > default to LRA. It bootstraps and regtests alpha once a week via qemu. > > > > > > I think it's testing the baseline configuration, so presumably non-BWX > > > variants. That can probably be adjusted if necessary. > > > > It does seem to fail when enabling M2 though: > > > > m2/pge -k -l ../../gcc/m2/gm2-compiler/P2Build.bnf -o m2/gm2-compiler-boot/P2Build.mod > > m2/pge -k -l ../../gcc/m2/gm2-compiler/P3Build.bnf -o m2/gm2-compiler-boot/P3Build.mod > > m2/pge -k -l ../../gcc/m2/gm2-compiler/PHBuild.bnf -o m2/gm2-compiler-boot/PHBuild.mod > > m2/pge -k -l ../../gcc/m2/gm2-compiler/PCBuild.bnf -o m2/gm2-compiler-boot/PCBuild.mod > > m2/pge -k -l ../../gcc/m2/gm2-compiler/P1Build.bnf -o m2/gm2-compiler-boot/P1Build.mod > > m2/pge -k -l ../../gcc/m2/gm2-compiler/P0SyntaxCheck.bnf -o m2/gm2-compiler-boot/P0SyntaxCheck.mod > > terminate called after throwing an instance of 'unsigned int' > > make[3]: *** [../../gcc/m2/Make-lang.in:1778: m2/gm2-compiler-boot/P2Build.mod] Aborted > > make[3]: *** Deleting file 'm2/gm2-compiler-boot/P2Build.mod' > > make[3]: *** Waiting for unfinished jobs.... > > terminate called after throwing an instance of 'unsigned int' > > make[3]: *** [../../gcc/m2/Make-lang.in:1778: m2/gm2-compiler-boot/P0SyntaxCheck.mod] Aborted > > make[3]: *** Deleting file 'm2/gm2-compiler-boot/P0SyntaxCheck.mod' > > terminate called after throwing an instance of 'unsigned int' > > make[3]: *** [../../gcc/m2/Make-lang.in:1778: m2/gm2-compiler-boot/P1Build.mod] Aborted > > make[3]: *** Deleting file 'm2/gm2-compiler-boot/P1Build.mod' > > terminate called after throwing an instance of 'unsigned int' > > make[3]: *** [../../gcc/m2/Make-lang.in:1778: m2/gm2-compiler-boot/P3Build.mod] Aborted > > make[3]: *** Deleting file 'm2/gm2-compiler-boot/P3Build.mod' > > terminate called after throwing an instance of 'unsigned int' > > make[3]: *** [../../gcc/m2/Make-lang.in:1778: m2/gm2-compiler-boot/PHBuild.mod] Aborted > > make[3]: *** Deleting file 'm2/gm2-compiler-boot/PHBuild.mod' > > terminate called after throwing an instance of 'unsigned int' > > make[3]: *** [../../gcc/m2/Make-lang.in:1778: m2/gm2-compiler-boot/PCBuild.mod] Aborted > > make[3]: *** Deleting file 'm2/gm2-compiler-boot/PCBuild.mod' > > Disabling M2 is enough to fix this. For practical purposes all reload->LRA conversions should focus on C and C++. Everything else is optional and not required to keep a port live (I'd argue it's wasting cycles to look at anything beyond C/C++ until those work with a mostly clean testsuite). Richard. > Thus, GCC bootstraps fine with LRA if one disables M2 and uses EV56 as the baseline. > > I will run the testsuite now for both Reload and LRA. > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer > `. `' Physicist > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On Wed, 2024-10-16 at 09:39 +0200, Richard Biener wrote: > > Disabling M2 is enough to fix this. > > For practical purposes all reload->LRA conversions should focus on C > and C++. Everything > else is optional and not required to keep a port live (I'd argue it's > wasting cycles to look > at anything beyond C/C++ until those work with a mostly clean testsuite). So far I have found two issues: One is the LRA build failing on non-BWX targets and the other is the M2 failure. I'll open bug reports for these. In any case, I'm glad that Alpha bootstraps mostly fine with LRA enabled. Adrian
diff --git a/gcc/config/alpha/alpha.cc b/gcc/config/alpha/alpha.cc index 74631a41693..218c66b6090 100644 --- a/gcc/config/alpha/alpha.cc +++ b/gcc/config/alpha/alpha.cc @@ -9941,6 +9941,14 @@ alpha_c_mode_for_floating_type (enum tree_index ti) return default_mode_for_floating_type (ti); } +/* Implement TARGET_LRA_P. */ + +static bool +alpha_use_lra_p () +{ + return alpha_lra_p; +} + /* Initialize the GCC target structure. */ #if TARGET_ABI_OPEN_VMS # undef TARGET_ATTRIBUTE_TABLE @@ -10124,7 +10132,7 @@ alpha_c_mode_for_floating_type (enum tree_index ti) #endif #undef TARGET_LRA_P -#define TARGET_LRA_P hook_bool_void_false +#define TARGET_LRA_P alpha_use_lra_p #undef TARGET_LEGITIMATE_ADDRESS_P #define TARGET_LEGITIMATE_ADDRESS_P alpha_legitimate_address_p diff --git a/gcc/config/alpha/alpha.opt b/gcc/config/alpha/alpha.opt index 62543d2689c..a4d6d58724a 100644 --- a/gcc/config/alpha/alpha.opt +++ b/gcc/config/alpha/alpha.opt @@ -89,6 +89,11 @@ mlarge-text Target RejectNegative InverseMask(SMALL_TEXT) Emit indirect branches to local functions. +mlra +Target Var(alpha_lra_p) Undocumented +Usa LRA for reload instead of the old reload framework. This option is +experimental, and it may be removed in future versions of the compiler. + mtls-kernel Target Mask(TLS_KERNEL) Emit rdval instead of rduniq for thread pointer. diff --git a/gcc/config/alpha/alpha.opt.urls b/gcc/config/alpha/alpha.opt.urls index a55c08328c3..916a3013f63 100644 --- a/gcc/config/alpha/alpha.opt.urls +++ b/gcc/config/alpha/alpha.opt.urls @@ -44,6 +44,8 @@ UrlSuffix(gcc/DEC-Alpha-Options.html#index-msmall-data) mlarge-data UrlSuffix(gcc/DEC-Alpha-Options.html#index-mlarge-data) +; skipping UrlSuffix for 'mlra' due to finding no URLs + msmall-text UrlSuffix(gcc/DEC-Alpha-Options.html#index-msmall-text)
PR target/66207 * config/alpha/alpha.opt (mlra): New target option. * config/alpha/alpha.cc (alpha_use_lra_p): New function. (TARGET_LRA_P): Use it. * config/alpha/alpha.opt.urls: Regenerate. Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> --- gcc/config/alpha/alpha.cc | 10 +++++++++- gcc/config/alpha/alpha.opt | 5 +++++ gcc/config/alpha/alpha.opt.urls | 2 ++ 3 files changed, 16 insertions(+), 1 deletion(-) v2: - Rephrase patch short summary