Minor regression due to recent IRA changes

Oleg Endo oleg.endo@t-online.de
Sat Feb 29 15:47:00 GMT 2020


On Fri, 2020-02-28 at 13:24 -0700, Jeff Law wrote:
> This change:
> 
> > commit 3133bed5d0327e8a9cd0a601b7ecdb9de4fc825d
> > Author: Vladimir N. Makarov <vmakarov@redhat.com>
> > Date:   Sun Feb 23 16:20:05 2020 -0500
> > 
> >     Changing cost propagation and ordering colorable bucket
> > heuristics for
> > PR93564.
> >     
> >     2020-02-23  Vladimir Makarov  <vmakarov@redhat.com>
> >     
> >             PR rtl-optimization/93564
> >             * ira-color.c (struct update_cost_queue_elem): New
> > member start.
> >             (queue_update_cost, get_next_update_cost): Add new arg
> > start.
> >             (allocnos_conflict_p): New function.
> >             (update_costs_from_allocno): Add new arg
> > conflict_cost_update_p.
> >             Add checking conflicts with allocnos_conflict_p.
> >             (update_costs_from_prefs, restore_costs_from_copies):
> > Adjust
> >             update_costs_from_allocno calls.
> >             (update_conflict_hard_regno_costs): Add checking
> > conflicts with
> >             allocnos_conflict_p.  Adjust calls of queue_update_cost
> > and
> >             get_next_update_cost.
> >             (assign_hard_reg): Adjust calls of
> > queue_update_cost.  Add
> >             debugging print.
> >             (bucket_allocno_compare_func): Restore previous
> > version.
> > 
> 
> Is causing c-torture/compile/sync-1 to fail with an ICE on sh4eb
> (search for
> "Tests that now fail, but worked before":
> 
> 
> http://3.14.90.209:8080/job/sh4eb-linux-gnu/lastFailedBuild/console
> 
> 
> In the .log we have:
> 
> > /home/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/sync-1.c:253:1:
> > error:
> > unable to find a register to spill in class 'R0_REGS'^M
> > /home/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/sync-1.c:253:1:
> > error: this
> > is the insn:^M
> > (insn 209 207 212 2 (parallel [^M
> >             (set (subreg:SI (reg:HI 431) 0)^M
> >                 (unspec_volatile:SI [^M
> >                         (mem/v:HI (reg/f:SI 299) [-1  S2 A16])^M
> >                         (subreg:HI (reg:SI 6 r6 [orig:425 uc+-3 ]
> > [425]) 2)^M
> >                         (reg:HI 5 r5 [orig:428 sc+-1 ] [428])^M
> >                     ] UNSPECV_CMPXCHG_1))^M
> >             (set (mem/v:HI (reg/f:SI 299) [-1  S2 A16])^M
> >                 (unspec_volatile:HI [^M
> >                         (const_int 0 [0])^M
> >                     ] UNSPECV_CMPXCHG_2))^M
> >             (set (reg:SI 147 t)^M
> >                 (unspec_volatile:SI [^M
> >                         (const_int 0 [0])^M
> >                     ] UNSPECV_CMPXCHG_3))^M
> >             (clobber (scratch:SI))^M
> >             (clobber (reg:SI 0 r0))^M
> >             (clobber (reg:SI 1 r1))^M
> >         ]) "/home/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/sync-
> > 1.c":245:8 
> > 406 {atomic_compare_and_swaphi_soft_gusa}^M
> >      (expr_list:REG_DEAD (reg:HI 5 r5 [orig:428 sc+-1 ] [428])^M
> >         (expr_list:REG_DEAD (reg:SI 6 r6 [orig:425 uc+-3 ] [425])^M
> >             (expr_list:REG_DEAD (reg/f:SI 299)^M
> >                 (expr_list:REG_UNUSED (reg:HI 431)^M
> >                     (expr_list:REG_UNUSED (reg:SI 1 r1)^M
> >                         (expr_list:REG_UNUSED (reg:SI 0 r0)^M
> >                             (nil))))))))^M
> > 
> 
> You should be able to trigger it with a cross compiler at -O2 with
> the attached
> testcase.
> 
> This could well be a target issue.  I haven't tried to debug it.  If
> it's a
> target issue, I'm fully comfortable punting it to the SH folks for
> resolving.

The R0_REGS spill failure is a general problem, in particular with old
reload.  The atomic patterns tend to trigger it in one circumstance or
the other.  The IRA change probably just stresses it more.  Perhaps it
will go away with -mlra.

However, LRA on SH still has its own issues, so it can't be generally
enabled by default yet, unfortunately.  See also some of the recent
posts in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93877

Cheers,
Oleg



More information about the Gcc-patches mailing list