Re: some Sparc hackery in the works

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

   Date: Mon, 13 Jul 1998 21:48:37 -0600
   From: Jeffrey A Law <law@hurl.cygnus.com>

     In message <199807131854.TAA18918@phal.cygnus.co.uk>you write:
     > You usually get worse code if you try to open-code DImode operations as
     > RTL at rtl generation time.

   This depends on numerous factors, including but not limited to how many
   registers the target has and how important scheduling is for good performance
   on the target.

     > You can get the same benefit for scheduling and delay slot filling if you
     > povide define_splits for the patterns in question; you can then also
     > safe the output template by replacing it with a '#', to indicate that
     > this pattern must be split.

   Not necessarily since you lose optimizations done by various other
   optimizers.  For example, the sub-parts of a DImode load become
   candidates for CSE, GCSE, combine, local alloc, etc.

   There's generally some tradeoff for each direction.  We should trust
   David to do the right thing for the sparc port.

There is a 3rd issue.  If you open code it early, you risk ending up
with a multi-insn output in the end.  The reason is fundamentally
because some bits of information (odd/even DI mode register alignment,
and actual address alignment for MEM moves) pop up near the end of
code gen depending upon what register allocators do (and subsequently
what stack slots go to which items etc.).  There is also an issue with
argument passing semantics of DI mode objects on 32-bit targets.

Look at my code for the movdi sequences and splits very carefully.  I
tried many combinations and approaches, and this was the first which
reliably gave me perfect 1<-->1 insn output in the end.

Some of my early open coding attempts caused many situations where at
the end, in the define_insn's, I had to detect the bad register number
of address alignment cases and fix it up.  This was bad and defeated
the purpose of the goals I had in mind.

Thus I made everything a post-reload split... oh, always keep in mind
that all these move patterns are "special" anyways due to reload.

   ps.  Much of Dave's work mirrors stuff rth and myself have discussed
   as important to handle better on the sparc port.

BTW, during my work I noticed how much tha PA port is derived from or
influenced by the Sparc stuff, perhaps you can easily steal some of my
tricks and techniques ;-)

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