This is the mail archive of the 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: patch for killing cc0 users

  In message <>you write:
  > On Thu, Sep 17, 1998 at 12:21:33PM +0100, Joern Rennecke wrote:
  > > I think we get better code if we put a REG_UNUSED note for cc0 on the
  > > cc0 setter (or is it already there?), and not consider this insn
  > > a cc0 setter that has to have a matching cc0 user anymore.
  > One might argue that there is in fact one bug (in reg-stack)
  > and one missed optimization (in combine). 
  > However, I expect the situation in which combine cannot also remove the
  > cc0 setter to happen basically never.  I've no idea how I would go about
  > tracking down other potential cc0 mismatches, so I thought it best to 
  > just let it be.
According to cse.c:

#ifdef HAVE_cc0
  /* If the previous insn set CC0 and this insn no longer references CC0,
     delete the previous insn.  Here we use the fact that nothing expects CC0
     to be valid over an insn, which is true until the final pass.  */
  if (prev_insn && GET_CODE (prev_insn) == INSN
      && (tem = single_set (prev_insn)) != 0
      && SET_DEST (tem) == cc0_rtx
      && ! reg_mentioned_p (cc0_rtx, x))
      PUT_CODE (prev_insn, NOTE);
      NOTE_SOURCE_FILE (prev_insn) = 0;

  prev_insn_cc0 = this_insn_cc0;
  prev_insn_cc0_mode = this_insn_cc0_mode;

However, combine create insns which have a set of CC0 in parallel with
another operation (search for HAVE_cc0 in combine.c), so I do think
we do need to check for additional side effects before deleting the
cc0 setter insn.

In cases where we can't delete cc0 setter, we might just want to leave
the cc0 user alone, unless we know that passes after combine will
honor a REG_UNUSED note for cc0.


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