> > >> You also don't mention how this patch was tested. > > I used the testsuite I developed some time ago to test all the Neon > builtins, which I posted last year on the qemu mailing-list. With the > current GCCs, this bug is the only remaining one I could detect. >
Fair enough. > >> Alternatively it might be worth splitting the >> vld1q_*64 case into a 64 bit load into a (subreg:DI (V2DI reg) 0 ) >> followed by a subreg to subreg move which should end up having the >> same effect . That splitting would allow for better instruction >> scheduling. > > Are you aware of examples of similar cases I could use as a model? I would change the iterator from VQX to VQ in the pattern above (you can also simplify the setting of neon_type in that case as well as change that to be a vec_duplicate as below and get rid of any lingering definitions of UNSPEC_VLD1_DUP if they exist), define a separate pattern that expressed this as a define_insn_and_split as below. (define_insn_and_split "neon_vld1_dupv2di" [(set (match_operand:V2DI 0 "s_register_operand" "=w") (vec_duplicate:V2DI (match_operand:DI 1 "neon_struct_operand" "Um")))] "TARGET_NEON" "#" "&& reload_completed" [(const_int 0)] { rtx tmprtx = gen_lowpart (DImode, operands[0]); emit_insn (gen_neon_vld1_dupdi (tmprtx, operands[1])); emit_move_insn (gen_highpart (DImode, operands[0]), tmprtx ); DONE; } (set_attr "length" "8") (set_attr "neon_type" "<fromearlierpattern">) ) Do you want to try this and see what you get ? > > >> In addition it would be nice to have a testcase in >> gcc.target/arm . > > Well. Prior to sending my patch I did look at that directory, but I supposed > that such a test ought to belong to the neon/ subdir where the tests are > described as autogenerated. Any doc on how to do that? I'd rather have an extra regression test in gcc.target/arm that was a run time test. for e.g. take a look at gcc.target/arm/neon-vadds64.c . Ramana > > Thanks, > > Christophe. >