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"