Re: some Sparc hackery in the works

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

  In message <199807131107.EAA11110@dm.cobaltmicro.com>you write:
  > The work is very preliminary, but I've made much progress.  It won't
  > make it into the upcoming 1.1 release, but I will merge it in soon
  > afterwards.
Agreed.

  > So I figured that I'd put my latest patches up for FTP for those who
  > want to take a look and maybe contribute more improvements or just
  > plain regression test what I have so far.  Feel free to do either.
Another option is to make a branch for this work.  That way the latest
bits are always in CVS.  Folks that want to look at or help with the
code just check out the magic branch.

  > 1) Make all RTL ever generated by the Sparc back end have a
  >    one to one correspondance between RTL insns and real Sparc
  >    insns.
Yippie!

  >    For certain classes of operations the Sparc backend currently
  >    generates multiple sparc insns per RTL insn.  This is bad for
  >    two reasons:
  > 
  > 	a) Less accurate schedules are obtained
  > 	b) reorg can't fill as many delay slots
  > 
  >    The first major obstacle here were the move patterns.  I rewrote
  >    them completely, happily half of sparc.c disappeared as things
  >    such as emit_move_sequence, output_move_double etc. were no longer
  >    needed.
Yup.  This is traditionally where this kind of work gets hard.

  > 3) Complete removal of any references to hard integer registers in the
  >    Sparc machine description.  The main incentive is that such
  >    hard-coded registers prevent CSE from occuring.
Awsome.  These hard registers also prevent certain combining, hoisting
out of loops, gcse, etc.  Explicitly mentioned hard registers are 
generally a lose.

jeff