Is there a case or PR to demonstrate the issue? If yes, better to
include it as a test case.
Thanks,
Joey
On Thu, Nov 13, 2014 at 2:14 PM, Yangfei (Felix) <felix.y...@huawei.com> wrote:
> Hi,
>
> We find that the VALLDI mode iterator used in *aarch64_simd_ld1r<mode>
> pattern is not appropriate.
> The reason is that it's impossible to get a new operand of DImode by
> vec_duplicating an operand of the same mode.
> So this patch just excludes the DImode and uses VALL instead.
> Reg-tested for aarch64-linux-gnu with QEMU. OK for the trunk?
>
>
> Index: gcc/ChangeLog
> ===================================================================
> --- gcc/ChangeLog (revision 217394)
> +++ gcc/ChangeLog (working copy)
> @@ -1,3 +1,9 @@
> +2014-11-13 Felix Yang <felix.y...@huawei.com>
> + Jiji Jiang <jiangj...@huawei.com>
> +
> + * config/aarch64/aarch64-simd.md (*aarch64_simd_ld1r<mode>): Use
> + VALL mode iterator instead of VALLDI.
> +
> 2014-11-11 Andrew Pinski <apin...@cavium.com>
>
> Bug target/61997
> Index: gcc/config/aarch64/aarch64-simd.md
> ===================================================================
> --- gcc/config/aarch64/aarch64-simd.md (revision 217394)
> +++ gcc/config/aarch64/aarch64-simd.md (working copy)
> @@ -4936,8 +4936,8 @@
> })
>
> (define_insn "*aarch64_simd_ld1r<mode>"
> - [(set (match_operand:VALLDI 0 "register_operand" "=w")
> - (vec_duplicate:VALLDI
> + [(set (match_operand:VALL 0 "register_operand" "=w")
> + (vec_duplicate:VALL
> (match_operand:<VEL> 1 "aarch64_simd_struct_operand" "Utv")))]
> "TARGET_SIMD"
> "ld1r\\t{%0.<Vtype>}, %1"
