This is the mail archive of the gcc-patches@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]

Re: Reload patch v4



  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


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