This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug rtl-optimization/84842] [7/8 Regression] ICE in verify_target_availability, at sel-sched.c:1569
- From: "abel at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 24 Apr 2018 14:45:31 +0000
- Subject: [Bug rtl-optimization/84842] [7/8 Regression] ICE in verify_target_availability, at sel-sched.c:1569
- Auto-submitted: auto-generated
- References: <bug-84842-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84842
--- Comment #12 from Andrey Belevantsev <abel at gcc dot gnu.org> ---
(In reply to Alexander Monakov from comment #11)
> Thanks, I managed to reproduce it. The unusual thing here is hardreg 63
> being considered call-clobbered in its reg_raw_mode=TImode but not narrower
> modes. We have
>
> (insn 97 29 98 4 (set (reg:DI 63 31 [160])
> (unspec:DI [
> (reg:SI 29 29)
> ] UNSPEC_LFIWAX)) "pr84842.i":5 344 {lfiwax}
> (expr_list:REG_DEAD (reg:SI 29 29)
> (nil)))
>
> and sched-deps noting a REG_DEP_OUTPUT dependence on regno 63 against a
> preceding call insn according to rs6000_hard_regno_call_part_clobbered
> (regno=63, mode=E_TImode). I assume what the backend in conveying there is
> that only the low part of the register will be preserved by callees.
>
> However, when we move up the instruction we don't have a dependence. The LHS
> is DImode, so that seems correct as well: sched-deps had a more conservative
> answer because its dependence lists are not separated per mode.
>
> Andrey, does the above make sense? Can the assert be relaxed?
It does, but I'm not sure how to relax the assert -- it does check that we have
computed consistent data, as can be seen even from this PR. Maybe we need to
do always more conservative check like sched-deps, or on the contrary, make it
less conservative there (for stage 1)?