On 06/10/15 18:27, Renlin Li wrote:
> Hi all,
>
> Previously, the compiler will generate the following pattern, which will
> cause an ICE during postreload pass. Meanwhile, the instruction itself
> produces UNKNOWN result when the source and destination register are the same
> according to ARM instruction manual. The same rule applies to vtrn and vzip
> patterns.
>
> (insn 50 71 106 3 (parallel [
> (set (reg:V2SI 48 d16 [172])
> (unspec:V2SI [
> (reg:V2SI 48 d16 [172])
> (reg:V2SI 48 d16 [172])
> ] UNSPEC_VUZP1))
> (set (reg:V2SI 48 d16 [172])
> (unspec:V2SI [
> (reg:V2SI 48 d16 [172])
> (reg:V2SI 48 d16 [172])
> ] UNSPEC_VUZP2))
> ]) /src/gcc/gcc/testsuite/gcc.dg/vect/pr37474.c:21 1991
> {*neon_vuzpv2si_insn}
> (nil))
>
> The ICE is triggered when compiling gcc.dg/vect/pr37474.c using
> arm-none-linux-gnueabihf toolchain.
>
> Adding "&" modifier to operands[0] and operands[2] will explicitly prevent
> those two register operands getting the same register.
> I made the same changes to neon_vtrn<mode>_insn and neon_vzip<mode>_insn
> pattern as well.
>
> arm-none-linux-gnueabihf regression tests Okay. Okay to commit?
OK - please watch out for any fallout in the coming days.
After letting this bake for a few days please backport to all release branches
as this is a latent issue in the target that is purely dependent on the pattern.
regards
Ramana
>
> Regards,
> Renlin Li
>
> gcc/ChangeLog:
>
> 2015-10-06 Renlin Li <renlin...@arm.com>
>
> * config/arm/neon.md (neon_vuzp<mode>_insn): Add & modifier for
> operands[0] and operands[2].
> (neon_vtrn<mode>_insn): Likewise.
> (neon_vzip<mode>_insn): Likewise.
>
