Re: [Patch]: Fix pb in libcall_dead_p

[Stephane Carrez <Stephane dot Carrez at worldnet dot fr>]

Hi!

Richard Kenner a écrit :
> 
>     In fact, what happens is that when a movsi reload is made, either the
>     source or the destination is a hard register.  In that case, I don't
>     need a scratch.
> 
> So which cases *do* you need a scratch?  If only mem-mem, then the normal
> approach is to disallow mem-mem for movsi using the extra condition.

The 68hc11 has only three 16-bit registers: d, x, y.  If I disallow mem-mem or 
mem-cst, I need a SI hard reg which consumes 2 hard registers.  By using a 
clobber, I only use one. 

Because I have only 3 real hard regs, I have a notion of soft registers
which are in fact memory locations in page0.  But gcc thinks they are real
registers (this idea comes from a very old 6809 port with gcc 2.6.3).
Now, the soft register must support a move to another soft register.  
Since they are in memory, in fact, I need a clobber as temporary.

Here is how, I've defined the movsi:

(define_insn "movsi"
  [(set (match_operand:SI 0 "nonimmediate_operand" "=mu,?D,m,?D,?u,?u,!u,D")
	(match_operand:SI 1 "general_operand"      "imu,im,?D,!u,?D,mi,!u,!D"))
   (clobber (match_scratch:HI 2                    "=&d,X,X,X,X,&d,&d,X"))]
  ""
  "#")

'u' constraint represents a soft register.
'd' constraint represents the register d (the only one that allows arith+logical).
'D' constraint represents the only 32-bit hard register which is possible
    (x + d)

So, in the following cases, I don't need a clobber:

   D <-> mem
   D <-  const
   D <-> u

Now, in other cases:

  mem <-> mem
  mem <-  const
  u   <-> u			[These are registers for gcc]
  u   <-> mem
  u   <-  const

I need the 'd' register as a scratch.


>     I have a few DI operations also.  But for them, I've defined a clobber
>     and I've tried to make sure reloading of operands does not happen.
> 
> How can you possibly "make sure reloading of operands does not happen"?
> It's *far* better to put in the macros to make this work the way it's
> meant to.

Reloading for the operand can occur (I mean for the operand address for example).
But reloading of the operand does not.

The constraint accepts everything that the predicat permits.  In general,
there will be 'muiD' for SI source operands, and 'D' for SI destinations.

For DI modes, it's 'mu' or 'mui'.  So, everything is memory (but reg or mem for
gcc).

The SECONDARY_* will not help me at all in fact.  To do some arithmetic
computations, I need a hard register.  So the source/destination of the reload
is something I can move to/from without an additional register.

Now, to support a mem <-> mem move with a secondary reload, this will not
help me too.  I understand that GCC will allocate a SI reg and it will
split the mem <-> mem into

  reg <- mem
  mem <- reg

At this stage, the 'reg' will be a SImode so I need two hard 16-bit registers:

- If I choose to use a soft register ('u'), this is in fact a memory and the
  register itself does not help me (but it's right that I can use the secondary
  reload to do the copy).  The result of this is that there is really two
  SI memory moves.

- If I choose to use a hard register, the only choice is 'D' (d+x) and I don't
  need the secondary reload (this is my movsi pattern).


Finally, I found that the use of a clobber in the pattern was a nice solution
and I could generate quite efficient code.

	Stephane

-----------------------------------------------------------------------
         Home                               Office
E-mail: stcarrez@worldnet.fr               Stephane.Carrez@sun.com
WWW:    http://home.worldnet.fr/stcarrez   http://www.sun.com
Mail:   17, rue Foucher Lepelletier        6, avenue Gustave Eiffel
        92130 Issy Les Moulineaux          78182 Saint Quentin en Yvelines
        France