Hi All,
This patch fixes a bug in the SIMD mov pattern where we were doing an
insert and leaving the rest of the vector in an undetermined state. This
could cause a bug if something else expects the other lanes to be 0.
Semantically we wanted a mov here and not an insert. This is in line
with other patterns that use an fmov for the same reason,
e.g. aarch64_combinez*.
Regression tested on aarch64-none-linux-gnu and no regressions.
OK for trunk?
Thanks,
Tamar
gcc/
2017-03-15 Tamar Christina <tamar.christ...@arm.com>
* config/aarch64/aarch64-simd.md (*aarch64_simd_mov<mode>)
Change ins into fmov.
diff --git a/gcc/config/aarch64/aarch64-simd.md b/gcc/config/aarch64/aarch64-simd.md
index b61f79a09462b8cecca7dd2cc4ac0eb4be2dbc79..e8ec9489d111a2c9227d418386bbcf54c81d14ec 100644
--- a/gcc/config/aarch64/aarch64-simd.md
+++ b/gcc/config/aarch64/aarch64-simd.md
@@ -107,7 +107,7 @@
case 1: return "str\\t%d1, %0";
case 2: return "orr\t%0.<Vbtype>, %1.<Vbtype>, %1.<Vbtype>";
case 3: return "umov\t%0, %1.d[0]";
- case 4: return "ins\t%0.d[0], %1";
+ case 4: return "fmov\t%d0, %1";
case 5: return "mov\t%0, %1";
case 6:
return aarch64_output_simd_mov_immediate (operands[1],
@@ -116,8 +116,8 @@
}
}
[(set_attr "type" "neon_load1_1reg<q>, neon_store1_1reg<q>,\
- neon_logic<q>, neon_to_gp<q>, neon_from_gp<q>,\
- mov_reg, neon_move<q>")]
+ neon_logic<q>, neon_to_gp<q>, f_mcr,\
+ mov_reg, neon_move<q>")]
)
(define_insn "*aarch64_simd_mov<mode>"