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 #28 from Andrey Belevantsev <abel at gcc dot gnu.org> 2013-02-14 06:11:21 UTC ---
(In reply to comment #27)
> (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.

I agree with you in general, it's just this case of having extra dependencies
because an LHS hard register was substituted to a pseudo is non-intuitive to
me.  I am not aware of other similar cases when the "other dependency reasons"
you mention kick in after such transformation.  So I'll try going with the
minimal fix of tracking only this particular case (of newly created implicit
clobbers) in the selective scheduler.

Btw, does the code calculating implicit clobbers via
ira_implicitly_set_insn_hard_regs were planned just for the pressure sensitive
scheduling or also for the general case?  It looks like it is needed for the
former but it is calculated for the latter.


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