Re: condition codes, haifa-sched and virtual-stack-vars

[Geoff Keating <geoffk at geoffk dot org>]

> From: Ulrich Weigand <weigand@immd1.informatik.uni-erlangen.de>
> Date: Thu, 31 Jan 2002 00:16:59 +0100 (MET)
> Cc: weigand@immd1.informatik.uni-erlangen.de (Ulrich Weigand), gcc@gcc.gnu.org
> X-OriginalArrivalTime: 30 Jan 2002 23:24:42.0937 (UTC) FILETIME=[4BEAD290:01C1A9E5]
> 
> Geoff Keating wrote:
> 
> > Ulrich Weigand <weigand@immd1.informatik.uni-erlangen.de> writes:
> > 
> > > The problem is that reload simply calls gen_add2_insn whenever it
> > > feels like it, without consideration that this might introduce
> > > a CC clobber at an inappropriate point ...
> > 
> > On xstormy16, this problem existed with the carry register.  I believe
> > it was fixed by having a reload_inhi pattern and an appropriate
> > definition of SECONDARY_RELOAD_CLASS.  The result appears to work.
> 
> This is interesting, but I'm not sure I understand *why* it works ;-)
> 
> The reload_inhi pattern tries to allocate the carry register as the
> secondary reload scratch register.  Now, in the interesting case 
> where the carry register is in fact live at the location where the
> insn is inserted, this would mean that reload would need to spill
> the carry register and later on restore its old value, right?
> (Because there is only a single register in this class ...)

No, reload_inhi doesn't allocate anything; that's done by
SECONDARY_RELOAD_CLASS.  reload_inhi is just to explain to reload how
to put the carry register into the add instruction.

> However, I'm not sure how the carry register can be spilled,
> given that there is no mov* insn that touches it, unless I'm
> missing something ...

Yes, the case of spills is tricky, which is why we pretty much avoid
it on xstormy16 :-).  In the general case, you'd have to explain how
to spill and restore the carry register.  xstormy16 has the additional
problem that certain branches can clobber the carry register, which is
why it can't really be spilled (because reload is not smart enough to
restore it after a branch).

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>