This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug rtl-optimization/84842] [7/8 Regression] ICE in verify_target_availability, at sel-sched.c:1569


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)?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]