reload vs adds with clobbers

[DJ Delorie]

> Yes.  In fact, I thought that was already done for xstormy16, but I
> probably missed a case...

Ok, I figured out what was happening.  xstormy16 has two types of
add/sub instructions: add/sub with carry, and inc/dec without.

xstormy16_carry_plus_operand identifies the difference with this
statement:

  && (INTVAL (XEXP (x, 1)) < -4 || INTVAL (XEXP (x, 1)) > 4));

However, inc/dec cannot accept a constant of zero, which is the case
that fails - adding zero to a register.  The above thinks that this
case uses inc/dec, but the inc/dec constraints won't allow it:

  (match_operand:HI 2 "xs_hi_nonmemory_operand" "O,P,L,M,Ir,N,i")))

   : (C) == 'N' ? (VALUE) >= -3 && (VALUE) <= 0		\
   : (C) == 'O' ? (VALUE) >= 1 && (VALUE) <= 4		\
   : (C) == 'P' ? (VALUE) >= -4 && (VALUE) <= -1	\

Note that the case of zero is not allowed.

I can think of a few ways of addressing this:

I'm currently testing adding an !N constraint after the O,P ones, to
catch the zero case, with an output template of ";", assuming that gcc
will always choose the P constraint for non-zero cases.

We could change xstormy16_carry_plus_operand to allow zero, but then
we'd see the add opcode in the output stream (plus the need for a
carry).

We could use "#" as the output template, and define a splitter that
turns it into nothing.

We could split the addhi3 into a define_expand/define_insn pair, and
have the expander detect the zero case and emit nothing.  However, I
already noted that the expander is not used during reload, so I don't
think this will help.

We could find all the places in gcc where this add is created, and
detect the zero case there and just emit a move (or nothing).

Comments?