[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling

["abel at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889

Andrey Belevantsev <abel at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vmakarov at gcc dot gnu.org

--- Comment #21 from Andrey Belevantsev <abel at gcc dot gnu.org> 2013-01-23 11:11:22 UTC ---
Thanks again folks, it's much simpler with gdb.  So the reason of the
difference that shows up in the ICE is the ira_implicitly_set_insn_hard_regs
function.  Recall that we have insns 23 and 24 like this:

   23: r148:SI=[unspec[`*LC..2',%2:SI] 44]
   24: %3:SI=[unspec[`*LCM..2',%2:SI] 44]

and insn 17 like this:

   17: {%3:SI=unspec[%3:SI,%4:SI] 25;clobber %0:SI;clobber %4:SI;clobber
%5:SI;clobber %11:SI;clobber %0:CC;clobber lr:SI;}

The dependency between insns 23 and 17 is because insn 17 clobbers reg 65 (I
guess it is lr in the dump).  When analyzing insn 23,
ira_implicitly_set_insn_hard_regs is called and it notices we have a pseudo-reg
148.  The function attempts to restrict the insn movement by marking the
registers that might be required by the "strict" alternatives of the insn as
implicit clobbers.  For insn 23 it marks reg 65 from LINK_REGS ('l' constraint)
and reg 66 from CTR_REGS ('c' constraint AFAIR).  Now we have an
anti-dependency via clobbering reg 65 with insn 17.

Insn 24 already has the hard register assigned (%3), so the above logic does
not apply and we don't get the implicit clobbers on this insn and thus a
dependency with insn 17.

In short, the implicit clobbers thing disagrees with the assumption sel-sched
mades: that renaming a hard register to a pseudo is always possible given that
the resulting insn is recognized and will never create extra dependencies.

So the choices we have are as follows:

1) make the if (! reload_completed) at sched-deps.c:2805 also conditional on
-fsched-pressure and make sel-sched incompatible with -fsched-pressure by
disallowing to specify both options at the same time. That is,
-fselective-scheduling will disable -fsched-pressure with a note to the user.

2) make the selective scheduler account for the situation when renaming a hard
register to a pseudo register before reload with sched-pressure enabled might
create extra dependencies, then insn 24 will never be considered for renaming
and the problem will be fixed.

I can do either 1 or 2, no problem with any of those given enough time until
4.8.

Thoughts?