Re: The recent regclass.c change

[Jeffrey A Law <law at cygnus dot com>]

  In message <Pine.SOL.3.90.981005093603.2829B-100000@matula.informatik.rwth-aa
chen.de>you write:
  > There was a patch to reg_scan_mark_refs recently that returns silently when
  > a NULL rtx is encountered.
Yup.  My band-aid.  It wasn't meant to be permanent :-0

  > linux-2.1.123/drivers/char/vt.c on i586-linux.  I believe the change is
  > incorrect (or at least the real problem is not fixed).
The real problem is definitely not fixed.  Or more correctly, we needed to
decide if we wanted to traverse insns which appeared in the REG_WAS_0 note.

  > The function already distinguishes between two kinds of reg notes: those
  > which are EXPR_LIST (their contents are scanned) and those which are
  > INSN_LIST (their contents are insns, and they are not scanned).
Right.

  > So the
  > real problem is that we get a REG_WAS_0 note, which should be of the
  > INSN_LIST kind according to rtl.h, but which is in fact EXPR_LIST.
Ah.  That sounds like the core problem.  One of the questions I asked rth
when this originally came up was why we had an insn in an EXPR_LIST :-)  I
just didn't follow through enough on it.

  > The problem is in duplicate_loop_exit_test, which handles the REG_WAS_0
  > note thrice wrong:
  >  - it always makes EXPR_LISTs
  >  - it copies the contents, instead of making a reference to the insn
  >  - the new note most likely contains the wrong insn, if the referenced
  >    insn is part of the duplicated loop exit test.
Ah.

  > This patch undoes the regclass.c change and disables duplicate_loop_exit_te  > st
  > if a REG_WAS_0 note is found.
Instead of disabling duplicate_loop_exit_test, just remove the REG_WAS_0 note.
That's likely less intrusive from an optimization standpoint.  Note that cse2
might put it back, but it should do so in a safe way :-)

  > Do we actually need REG_WAS_0 still?  As far as I can see it is used in
  > three machine descriptions to turn movl 0,reg to incl reg.  The same
  > transformation ought to be done by the new reload_move2add pass, oughtn't
  > it?
Excellent question.  I'd say it's probably no longer needed, but we'd have to
do a little testing.

In theory, the code in i386.md which uses REG_WAS_0 should never trigger
anymore (since the constant load should have been replaced with a mov2add
sequence).  I'd say pick a few big hunks of code (compiler, glibc, 2.1.xxx
kernel?) and see if the REG_WAS_0 code in i386.md ever triggers.  If not, then
I'd say kill REG_WAS_0.

jeff