No, we noticed this issue when improving the vld1(q?)_dup intrinsics. Thanks.
> 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"