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 middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling


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

--- Comment #27 from Vladimir Makarov <vmakarov at gcc dot gnu.org> 2013-02-06 21:36:59 UTC ---
(In reply to comment #26)
> You are right, your suggestions is what I sketched in comment #21 as choices 1
> or 2.  Sorry for my unclear expalanation of what was actually happening.
> 
> I don't have a problem with making sel-sched have extra checks when renaming
> registers before reload, which will make us notice a not obvious extra
> dependence and avoid renaming properly, as now we've figured out these
> dependences don't follow immediately from the RTL.  I just want an extra
> opinion on whether such unexpected dependencies arising when a target (hard)
> register is replaced by a pseudo register should be normal within GCC, or do we
> attribute such dependencies only to the register pressure scheduling mode. 
> FWIW, I would rather agree with the latter than with the former.

I guess you can not fully assume that dependencies are created only from RTL
data flow.  There are cases (besides pressure sensitive scheduling case
mentioned here) when dependencies are still created for other reasons different
from RTL data flow.  I'd look at the dependencies as constraints resulting in
correct and *desirable* insn schedule.  Although overwhelming majority of them
are created from RTL data flow analysis.


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