------- Comment #4 from ramana at gcc dot gnu dot org 2010-04-08 22:57 -------
I think this is one more case of the ARM backend lying to the general
infrastructure.
We expand into ld4qav8hi which happens to be in this following form. Note if
you look at init_regs, there is no use of reg:XI 136 before this point, thus
data flow assumes that insn 12 is using an uninitialized value in this process.
(insn 12 10 13 3 /tmp/n.c:13 (parallel [
(set (reg:XI 136 [ D.3722 ])
(unspec:XI [
(mem:XI (reg/v/f:SI 141 [ src ]) [0 S64 A64])
(reg:XI 136 [ D.3722 ])
(unspec:V8HI [
(const_int 0 [0x0])
] 191)
] 111))
Why do we need the reg:XI 136 inside the UNSPEC here ? We could very well do
without that in the UNSPEC because all we are saying is that an XImode value is
written to by the load from the memory location described . I'm not an expert
on the Neon backend and thus someone else who knows more about the Neon backend
should comment about this one.
Thus the patch that I am testing is as below which atleast seems to fix the ICE
and didn't show any other issues.
Index: neon.md
===================================================================
--- neon.md (revision 158138)
+++ neon.md (working copy)
@@ -4711,26 +4711,25 @@ (define_insn "neon_vld4<mode>"
)
(define_expand "neon_vld4<mode>"
- [(match_operand:XI 0 "s_register_operand" "=w")
- (match_operand:SI 1 "s_register_operand" "+r")
+ [(match_operand:XI 0 "s_register_operand" "")
+ (match_operand:SI 1 "s_register_operand" "")
(unspec:VQ [(const_int 0)] UNSPEC_VSTRUCTDUMMY)]
"TARGET_NEON"
{
- emit_insn (gen_neon_vld4qa<mode> (operands[0], operands[0],
+ emit_insn (gen_neon_vld4qa<mode> (operands[0],
operands[1], operands[1]));
- emit_insn (gen_neon_vld4qb<mode> (operands[0], operands[0],
+ emit_insn (gen_neon_vld4qb<mode> (operands[0],
operands[1], operands[1]));
DONE;
})
(define_insn "neon_vld4qa<mode>"
[(set (match_operand:XI 0 "s_register_operand" "=w")
- (unspec:XI [(mem:XI (match_operand:SI 3 "s_register_operand" "2"))
- (match_operand:XI 1 "s_register_operand" "0")
+ (unspec:XI [(mem:XI (match_operand:SI 2 "s_register_operand" "1"))
(unspec:VQ [(const_int 0)] UNSPEC_VSTRUCTDUMMY)]
UNSPEC_VLD4A))
- (set (match_operand:SI 2 "s_register_operand" "=r")
- (plus:SI (match_dup 3)
+ (set (match_operand:SI 1 "s_register_operand" "=r")
+ (plus:SI (match_dup 2)
(const_int 32)))]
"TARGET_NEON"
{
@@ -4740,7 +4739,7 @@ (define_insn "neon_vld4qa<mode>"
ops[1] = gen_rtx_REG (DImode, regno + 4);
ops[2] = gen_rtx_REG (DImode, regno + 8);
ops[3] = gen_rtx_REG (DImode, regno + 12);
- ops[4] = operands[2];
+ ops[4] = operands[1];
output_asm_insn ("vld4.<V_sz_elem>\t{%P0, %P1, %P2, %P3}, [%4]!", ops);
return "";
}
@@ -4749,12 +4748,11 @@ (define_insn "neon_vld4qa<mode>"
(define_insn "neon_vld4qb<mode>"
[(set (match_operand:XI 0 "s_register_operand" "=w")
- (unspec:XI [(mem:XI (match_operand:SI 3 "s_register_operand" "2"))
- (match_operand:XI 1 "s_register_operand" "0")
+ (unspec:XI [(mem:XI (match_operand:SI 2 "s_register_operand" "1"))
(unspec:VQ [(const_int 0)] UNSPEC_VSTRUCTDUMMY)]
UNSPEC_VLD4B))
- (set (match_operand:SI 2 "s_register_operand" "=r")
- (plus:SI (match_dup 3)
+ (set (match_operand:SI 1 "s_register_operand" "=r")
+ (plus:SI (match_dup 2)
(const_int 32)))]
"TARGET_NEON"
{
@@ -4764,7 +4762,7 @@ (define_insn "neon_vld4qb<mode>"
ops[1] = gen_rtx_REG (DImode, regno + 6);
ops[2] = gen_rtx_REG (DImode, regno + 10);
ops[3] = gen_rtx_REG (DImode, regno + 14);
- ops[4] = operands[2];
+ ops[4] = operands[1];
output_asm_insn ("vld4.<V_sz_elem>\t{%P0, %P1, %P2, %P3}, [%4]!", ops);
return "";
}
Also the constraints in this expander routine are probably superfluous and
could be corrected.
(define_expand "neon_vld4<mode>"
[(match_operand:XI 0 "s_register_operand" "=w")
(match_operand:SI 1 "s_register_operand" "+r")
(unspec:VQ [(const_int 0)] UNSPEC_VSTRUCTDUMMY)]
"TARGET_NEON"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43590
