rs6000.md/altivec.md problem in setting of vector registers

[David Edelsohn]

>>>>> Dorit Naishlos writes:

Dorit> Actually, if you try to compile the above program with -maltivec, you'll
Dorit> get ICE'd during reload with the following error:

Dorit> simd-inv.c: In function `foo5':
Dorit> simd-inv.c:29: error: unrecognizable insn:
Dorit> (insn 88 87 89 0 (set (mem:V8HI (reg:SI 9 r9) [0 S16 A8])
Dorit> (reg:V8HI 2 r2 [126])) -1 (nil)
Dorit> (nil))
Dorit> simd-inv.c:29: internal compiler error: in extract_insn, at recog.c:2083

Dorit> This is because of a restriction I added a month ago to the following
Dorit> define_insn in altivec.md (last 2 lines):

Dorit> (define_insn "*movv8hi_internal1"
Dorit> [(set (match_operand:V8HI 0 "nonimmediate_operand" "=m,v,v,o,r,r,v")
Dorit> (match_operand:V8HI 1 "input_operand" "v,m,v,r,o,r,W"))]
Dorit> "TARGET_ALTIVEC
>>> && (altivec_register_operand (operands[0], V8HImode)
>>> || altivec_register_operand (operands[1], V8HImode))"

Dorit> If I remove the above 2 lines, compilation succeeds; However... we get the
Dorit> same inefficiencies that brought us to add these 2 lines in the first place
Dorit> (loop invariants don't get pulled out -
Dorit> http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02884.html);

	The patch applied to mainline was slightly different:

(define_insn "*movv8hi_internal1"
  [(set (match_operand:V8HI 0 "nonimmediate_operand" "=m,v,v,o,r,r,v")
        (match_operand:V8HI 1 "input_operand" "v,m,v,r,o,r,W"))]
  "TARGET_ALTIVEC 
   && (register_operand (operands[0], V8HImode) 
       || register_operand (operands[1], V8HImode))"

exactly because of the type of failure you see.  You should correct the
patterns in LNO branch.

David