some Sparc hackery in the works

["David S. Miller" <davem at dm dot cobaltmicro dot com>]

I've been tooling in the background on some Sparc backend rewrites to
improve code in general, and in particular for 64-bit targets.  The
latter was my original goal when I began these changes.

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.

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.

First, some caveats:

1) 64-bit targets are completely broken, don't even try to use it yet.
   This will be fixed soon.

2) JFC's VIS hacks are not completely back in with my changes,
   again this will be fixed soon.

All 32-bit non-VIS/non-v8plus targets should work just fine.

Next, what I was trying to accomplish:

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

   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.

   The remaining cases (most of which I haven't gotten to yet) to fix
   this issue completely have to do with multi-register (DI mode etc.)
   integer operations on sparc32, some PIC patterns, and the next
   topic.

2) Output more efficient constant moves and symbol references on
   64-bit targets, in all code models.

   This was the major fallacy I saw which gave me incentive to work
   on these rewrites.  Currently the 64-bit sparc backend produces
   ill sequences of code to load constants, such as:

   sethi	%hi(const), %tmp
   or		%tmp, %lo(const), %tmp
   sllx		%tmp, 32, %tmp
   sethi	%hi(const), %dest
   or		%dest, %lo(const), %dest
   or		%dest, %tmp, %dest

   This will happen any time bits need to be set in the upper
   32-bits of a 64-bit DImode value.

   The current framework I have added makes this possible, the
   actual implementation is coming soon.  The one problem case
   which may be difficult to handle satisfactorily are symbol
   address loads in the ANYWHERE 64-bit code model.  Currently
   this requires a fixed hard register which brings me to...

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.

   There are two primary places where this occurs in the current Sparc
   backend, for the aforementioned 64-bit symbol loading case and for
   PIC on all sparc sub-targets.

   Richard Henderson has worked closely with me on some solutions for
   the PIC problems.

Richard has already improved PIC code gen for jump tables, especially
for -fPIC, in this patch set.

Anyways, the current state of my changes are up for grabs at:

ftp://ftp.cobaltmicro.com/pub/users/davem/egcs/sparc_movsi_rewrite.diff

This is against the latest CVS development sources.  Enjoy, and
comments are welcome.

Later,
David S. Miller
davem@dm.cobaltmicro.com