This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: rs6000.md/altivec.md problem in setting of vector registers
>>>>> 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