On Mon, May 25, 2026 at 10:30:03AM -0400, Vladimir Makarov wrote: > > On 5/16/26 4:03 AM, Stefan Schulze Frielinghaus wrote: > > From: Stefan Schulze Frielinghaus <[email protected]> > > > > During costing of IRA, pseudos with an equivalence are taken out of the > > equation by assigning MEM to those. However, during LRA, some > > equivalences are rejected which means those previously spilled pseudos > > are then definitely spilled. In some cases, like for PIC, we already > > know during IRA that an equivalence will be rejected during LRA. > > Therefore, do not assign MEM to those pseudos during IRA which means > > there is a fair chance that they get a register assigned in the end. > > > > The attached tests are all derived from glibc. Without this patch some > > pseudos are spilled resulting in stack frames just due to those spills. > > With this patch, no pseudos are spilled and no unnecessary stack frames > > are set up. > > > > Note, the added conjunct in find_costs_and_classes() is basically the > > negated form of the disjunct from lra_constraints() > > > > || (pic_offset_table_rtx > > && ((const_pool_ok_p (PSEUDO_REGNO_MODE (i), x) > > && (targetm.preferred_reload_class > > (x, lra_get_allocno_class (i)) == NO_REGS)) > > || contains_symbol_ref_p (x)))) > > > > except that IRAs reg_allocno_class() is used instead of LRAs > > lra_get_allocno_class(). > > > > gcc/ChangeLog: > > > > * ira-costs.cc (find_costs_and_classes): Do not honour equivs if > > they get rejected by LRA anyway. > > * ira-int.h (CONST_POOL_OK_P): Move CONST_POOL_OK_P here ... > > * lra-constraints.cc (CONST_POOL_OK_P): from there. > > > > gcc/testsuite/ChangeLog: > > > > * gcc.target/s390/ira-pic-spill-1.c: New test. > > * gcc.target/s390/ira-pic-spill-2.c: New test. > > * gcc.target/s390/ira-pic-spill-3.c: New test. > > --- > > > > Notes: > > Bootstrapped and regtested on > > - aarch64-unknown-linux-gnu > > - powerpc64le-unknown-linux-gnu > > - s390x-ibm-linux-gnu > > - x86_64-pc-linux-gnu > > Ok for mainline? > > > > Sometimes obvious changes in cost calculation my result in unexpected GCC > test suite failures (and it may be actually because of too strictly expected > generated code). But I hope it is not the case especially as you tested a > few targets.
Right, since I will be barely reachable next week, I will push this later ... just in case there is any fallout I have to deal with. Thanks for your reviews so far! Cheers, Stefan > > The patch is ok for me. Thank you for fixing it. >
