PATCH RFC: Fix ARM bug by splitting up iwmmxt_movsi_insn

[Richard Earnshaw]

> On Mon, Oct 13, 2003 at 10:12:47AM +0100, Richard Earnshaw wrote:
> > > +   switch (which_alternative)
> > > +   {
> > > +   case 0: return \"mov%?\\t%0, %1\";
> > > +   case 1: return \"mvn%?\\t%0, #%B1\";
> > > +   case 2: return \"ldr%?\\t%0, %1\";
> > > +   case 3: return \"str%?\\t%1, %0\";
> > > +   case 4: return \"tmcr%?\\t%0, %1\";
> > > +   case 5: return \"tmrc%?\\t%0, %1\";
> > > +   default: return arm_output_load_gr (operands);
> > > +  }"
> 
> If you do this then you need to fix arm_output_load_gr also.  At the
> minimum:
> 
>   if (GET_CODE (operands [1]) != MEM
>       || GET_CODE (sum = XEXP (operands [1], 0)) != PLUS
>       || GET_CODE (reg = XEXP (sum, 0)) != REG
>       || GET_CODE (offset = XEXP (sum, 1)) != CONST_INT
>       || ((INTVAL (offset) < 1024) && (INTVAL (offset) > -1024)))
>     return "wldrw%?\t%0, %1";
> 
> But wldrw is the unpredicable instruction which started all this.

If that's true then the tables in GAS are wrong as well.

  {"wldrw",      0xec100200, 5, ARM_CEXT_IWMMXT, do_iwmmxt_word_addr},
                            ^^
says that a condition code may appear after the fifth character (it should 
be zero if that isn't allowed).

The same is also true of wstrw:

  {"wstrw",      0xec000200, 5, ARM_CEXT_IWMMXT, do_iwmmxt_word_addr},

Argh! no, it gets worse...

In do_iwmmxt_word_addr() we have

  if (wc_register (reg))
    {
      inst.instruction |=  0xf0000100;
      inst.instruction &= ~0x00400000;
    }

Where's the test that the user hasn't emitted a conditional instruction 
that wasn't legal?

Is it really the case that whether or not wstrw is conditionally 
executable or not depends on the registers it was given?

R.