http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889
Vladimir Makarov <vmakarov at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |vmakarov at redhat dot com
--- Comment #29 from Vladimir Makarov <vmakarov at redhat dot com> 2013-02-14
16:48:24 UTC ---
(In reply to comment #28)
> (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.
For example, additional dependencies can be created when queues are too long to
speed up insn scheduling in some patalogical cases. The probability that it
happens is small but it still happens and selective scheduler can crash in this
case too.
> 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.
It was done to solve (or at least decrease the probability) reload crashes
(reload can not find a spill register) when the first insn scheduling is used.
