On Sat, 12 Apr 2014, Richard Sandiford wrote:
> I went ahead and applied the adjusted version of the patch to trunk
> as below (because I wanted to add a testcase too).
I believe you need to adjust constraints to ensure constant 0 is known to
produce a 16-bit instruction encoding where possible. Otherwise you'll
end up with suboptimal code when the instruction is in a branch delay
slot. E.g. here:
> --- gcc/config/mips/mips.md 2014-04-12 10:36:09.105788710 +0100
> +++ gcc/config/mips/mips.md 2014-04-12 10:38:48.925225200 +0100
> @@ -4437,7 +4437,7 @@ (define_expand "mov<mode>"
>
> (define_insn "*mov<mode>_internal"
> [(set (match_operand:IMOVE32 0 "nonimmediate_operand"
> "=d,!u,!u,d,e,!u,!ks,d,ZS,ZT,m,*f,*f,*d,*m,*d,*z,*a,*d,*B*C*D,*B*C*D,*d,*m")
> - (match_operand:IMOVE32 1 "move_operand"
> "d,J,Udb7,Yd,Yf,ZT,ZS,m,!ks,!u,dJ,*d*J,*m,*f,*f,*z,*d,*J*d,*a,*d,*m,*B*C*D,*B*C*D"))]
> + (match_operand:IMOVE32 1 "move_operand"
> "d,J,Udb7,Yd,Yf,ZT,ZS,m,!ks,!kb,dJ,*d*J,*m,*f,*f,*z,*d,*J*d,*a,*d,*m,*B*C*D,*B*C*D"))]
> "!TARGET_MIPS16
> && (register_operand (operands[0], <MODE>mode)
> || reg_or_0_operand (operands[1], <MODE>mode))"
using:
(match_operand:IMOVE32 1 "move_operand"
"d,J,Udb7,Yd,Yf,ZT,ZS,m,!ks,!kbJ,dJ,*d*J,*m,*f,*f,*z,*d,*J*d,*a,*d,*m,*B*C*D,*B*C*D"))]
will make:
jals foo
sw $0, 0($2)
be produced (6 bytes) rather than:
jal foo
sw $0, 0($2)
(8 bytes), because the "!kbJ"/"ZT" constraint pair will match rather than
more general "dJ"/"m". Likewise with the other two RTL patterns. I'm
fairly sure you'll be able to come up with an appropriate test case to
cover it (or to prove me wrong if I missed something here).
Maciej
