Re: [PATCH 12/28] mn10300: Re-write move patterns.

[Richard Henderson <rth at redhat dot com>]

On 01/18/2011 09:02 AM, Jeff Law wrote:
> IIRC returning an empty string for that case didn't work because the
> empty string had some kind of special meaning in final.  (This was 13 or
> 14 years ago, so please forgive the IIRC's :-)
> 
> The net result is I think you have to return something for those
> alternatives rather than an empty string.

Not since I've been working on GCC.  We do this a lot -- emit stuff by
hand then return "" to tell final that nothing else need be output.  If
you insist, we can continue to return nop here, but I don't think it's
necessary.

> It also seems to me that for movqi/movhi we want to severely disparage
> the address regs on the mn103.  IIRC for the base mn103 we would trigger
> reload failures if we didn't expose a0-a3 to the movqi/movhi patterns.
> However, while the a0-a3 regs can hold such values, they can't be used
> in arithmetic/logicals/etc in QI/HI mode.  So to avoid pessimizing code
> we exposed a0-a3 in the QI/HI mode moves, but ignored them for register
> class preferencing and severely disparaged them for reloading.

I have ignored them for register class preferencing:

> +(define_insn "*movqi_internal"
> +  [(set (match_operand:QI 0 "nonimmediate_operand" "=*r,D*r,D*r,D,m")
> +	   (match_operand:QI 1 "general_operand"      "  0,D*r,  i,m,D"))]

Note that for mn103, D*r resolves to a DATA_REGS preference, with
GENERAL_REGS used for the legal register set.

As for pessimising, I'm not sure what else really needs to be done, given
that the only other operation for which Q/HImode is valid is extension.

> It also looks like you lost the movu am33 variant for movqi/movhi.  I
> don't recall anything about that alternative, but I can hazard a guess
> that movu is smaller than the more generic mov instruction for certain
> constants.

It is still present in movhi:

>      case 1:
> +      if (TARGET_AM33
> +	  && CONST_INT_P (operands[1])
> +	  && IN_RANGE (INTVAL (operands[1]), 0x80, 0xff))
> +	return "movu %1,%0";

What I dropped were the useless extra tests for movu.  There's no point
in loading 0x80 via movu when -128 via mov is 1 byte smaller for QImode.

> It looks like you lost movu for the base mn103 in the movsi pattern and
> for all the parts in the movsf pattern (it may not matter there).

Err, base mn103 doesn't have movu at all.

As for movsf, movu would only be usable for a small set of subnormal
operands.  Combine that with wanting to load that subnormal into an
integer register, as opposed to a floating-point register, and I think
that is rare enough not to be useful.

It does look as if I'm missing an EXTENDED_REGISTER check there in some
of the tests; the sizes of mov imm vary a bit between data, addr, and
extended register sets...


r~