John David Anglin <dave.ang...@bell.net> writes:
> On 2023-11-16 4:52 p.m., Jeff Law wrote: >> >> >> On 11/16/23 10:54, John David Anglin wrote: >>> Tested on hppa-unknown-linux-gnu and hppa64-hp-hpux11.11. Committed >>> to trunk. >>> >>> This patch works around problem compiling python3.11 by improving >>> REG+D address handling. The change results in smaller code and >>> reduced register pressure. >>> >>> Dave >>> --- >>> >>> hppa: Revise REG+D address support to allow long displacements before reload >>> >>> In analyzing PR rtl-optimization/112415, I realized that restricting >>> REG+D offsets to 5-bits before reload results in very poor code and >>> complexities in optimizing these instructions after reload. The >>> general problem is long displacements are not allowed for floating >>> point accesses when generating PA 1.1 code. Even with PA 2.0, there >>> is a ELF linker bug that prevents using long displacements for >>> floating point loads and stores. >>> >>> In the past, enabling long displacements before reload caused issues >>> in reload. However, there have been fixes in the handling of reloads >>> for floating-point accesses. This change allows long displacements >>> before reload and corrects a couple of issues in the constraint >>> handling for integer and floating-point accesses. >>> >>> 2023-11-16 John David Anglin <dang...@gcc.gnu.org> >>> >>> gcc/ChangeLog: >>> >>> PR rtl-optimization/112415 >>> * config/pa/pa.cc (pa_legitimate_address_p): Allow 14-bit >>> displacements before reload. Simplify logic flow. Revise >>> comments. >>> * config/pa/pa.h (TARGET_ELF64): New define. >>> (INT14_OK_STRICT): Update define and comment. >>> * config/pa/pa64-linux.h (TARGET_ELF64): Define. >>> * config/pa/predicates.md (base14_operand): Don't check >>> alignment of short displacements. >>> (integer_store_memory_operand): Don't return true when >>> reload_in_progress is true. Remove INT_5_BITS check. >>> (floating_point_store_memory_operand): Don't return true when >>> reload_in_progress is true. Use INT14_OK_STRICT to check >>> whether long displacements are always okay. >> I strongly suspect this is going to cause problems in the end. >> >> I've already done what you're trying to do. It'll likely look fine >> for an extended period of time, but it will almost certainly break >> one day. Jeff, I don't suppose you could dig out the old bugs/commits just out of interest? > I could happen. If it happens and can't be fixed, it's easy enough to return > false in > pa_legitimate_address_p before reload. Maybe we could add an optimization > option for this. > > As it stands, the code improvement for python is significant. I don't think > f-m-o can fix things after reload. >a > Hopefully, Sam will test the change with various package builds on gentoo. > Debian is still on gcc-13. Yeah, happy to do that. We haven't got GCC 14 deployed in the wild, but we have it available for people who want to test and opt-in to it. Fingers crossed it's calm. I'll let you know if it isn't ;) > I'm not seeing any obvious problems in the gcc testsuite. It needs testing > on packages that do extensive > floating point calculations. OK, I'll focus on those. > > Dave
