This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Reload patch v4
- To: Bernd Schmidt <crux at pool dot informatik dot rwth-aachen dot de>
- Subject: Re: Reload patch v4
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Thu, 01 Oct 1998 03:02:27 -0600
- cc: egcs-patches at cygnus dot com
- Reply-To: law at cygnus dot com
In message <Pine.GSO.4.02A.9809091245160.6366-100000@matula.informatik.rwth-a
achen.de>you write:
> It seems that I accidentally deleted the line that sets INSN_CODE. Good
> that you spotted this. However, the mode is no longer relevant. The
> old code used to encode whether an insn needs reloading and/or eliminations
> in the machine mode; the new code has special fields need_reload and
> need_elim in struct insn_chain. But now I think I see another bug: if
> the new insn needs elimination, it isn't placed on the insns_need_elim
> chain by caller-save.c.
OK. I had a feeling the mode wasn't needed anymore. You should update the
.texi files since they mention what various modes on an INSN mean.
> > In build_insn_chain, don't you have to be prepared to handle a
> > REG_DEAD note for a SUBREG? Or is there some reason this can
> > not happen?
>
> flow.c only appears to be making REG_DEAD notes for full registers. I
> don't know whether SUBREGs can appear in other parts of the compiler.
> I just had a look at sched.c, it has a bit of code that does
Hmmm. If sched doesn't handle them, then you probably don't need to. sched
is pretty picky about death notes.
> If I remember correctly, it's because some files include reload.h, but
> not hard-reg-set.h, and that leads to compilation errors.
Ah. Depending on the file(s), it might just be best to go ahead and include
hard-reg-set.h where we need it.
> > + /* Let's try without this, I can't see a reason for doing this. */
> > + #if defined ELIMINABLE_REGS && 0
> > + /* If registers other than the frame pointer are eliminable, mark the
> m as
> > + poor choices. */
> > + for (i = 0; i < NUM_ELIMINABLE_REGS; i++)
> > + SET_HARD_REG_BIT (bad_spill_regs, reg_eliminate[i].from);
> > +
> > + #endif
> >
> > You should reenable this code. Imagine a machine which uses an arg
> > pointer ;-) You really don't want to spill it if at all possible.
> > Similarly if the machine has other eliminable regs.
>
> Why not, if it is going to be eliminated?
But you can not guarantee that any particular elimination will happen. In fact,
you can't know if a particular elimination is safe until after the big while
loop later in the function.
jeff