On Mon, Jun 26, 2017 at 11:50 AM, Tamar Christina <tamar.christ...@arm.com> wrote: > Hi all, > > Here's the re-spun patch. > Aside from the grouping of the split patterns it now also uses h register for > the fmov for HF when available, > otherwise it forces a literal load. > > Regression tested on aarch64-none-linux-gnu and no regressions. Hi, There are lots of test failures on aarch64_be-none-elf, I verified two: gcc.dg/vect/pr61680.c execution test gcc.dg/vect/pr63148.c execution test
are caused by svn+ssh://gcc.gnu.org/svn/gcc/trunk@250673 Given review comment already pointed out big-endian issue and patch was updated to address it, I would expect reg-test on a big-endian target before applying patch, right? Thanks, bin > > OK for trunk? > > Thanks, > Tamar > > > gcc/ > 2017-06-26 Tamar Christina <tamar.christ...@arm.com> > Richard Sandiford <richard.sandif...@linaro.org> > > * config/aarch64/aarch64.md (mov<mode>): Generalize. > (*movhf_aarch64, *movsf_aarch64, *movdf_aarch64): > Add integer and movi cases. > (movi-split-hf-df-sf split, fp16): New. > (enabled): Added TARGET_FP_F16INST. > * config/aarch64/iterators.md (GPF_HF): New. > ________________________________________ > From: Tamar Christina > Sent: Wednesday, June 21, 2017 11:48:33 AM > To: James Greenhalgh > Cc: GCC Patches; nd; Marcus Shawcroft; Richard Earnshaw > Subject: RE: [PATCH][GCC][AArch64] optimize float immediate moves (2 /4) - > HF/DF/SF mode. > >> > movi\\t%0.4h, #0 >> > - mov\\t%0.h[0], %w1 >> > + fmov\\t%s0, %w1 >> >> Should this not be %h0? > > The problem is that H registers are only available in ARMv8.2+, > I'm not sure what to do about ARMv8.1 given your other feedback > Pointing out that the bit patterns between how it's stored in s vs h registers > differ. > >> >> > umov\\t%w0, %1.h[0] >> > mov\\t%0.h[0], %1.h[0] >> > + fmov\\t%s0, %1 >> >> Likewise, and much more important for correctness as it changes the way the >> bit pattern ends up in the register (see table C2-1 in release B.a of the ARM >> Architecture Reference Manual for ARMv8-A), here. >> >> > + * return aarch64_output_scalar_simd_mov_immediate (operands[1], >> > + SImode); >> > ldr\\t%h0, %1 >> > str\\t%h1, %0 >> > ldrh\\t%w0, %1 >> > strh\\t%w1, %0 >> > mov\\t%w0, %w1" >> > - [(set_attr "type" >> "neon_move,neon_from_gp,neon_to_gp,neon_move,\ >> > - f_loads,f_stores,load1,store1,mov_reg") >> > - (set_attr "simd" "yes,yes,yes,yes,*,*,*,*,*")] >> > + "&& can_create_pseudo_p () >> > + && !aarch64_can_const_movi_rtx_p (operands[1], HFmode) >> > + && !aarch64_float_const_representable_p (operands[1]) >> > + && aarch64_float_const_rtx_p (operands[1])" >> > + [(const_int 0)] >> > + "{ >> > + unsigned HOST_WIDE_INT ival; >> > + if (!aarch64_reinterpret_float_as_int (operands[1], &ival)) >> > + FAIL; >> > + >> > + rtx tmp = gen_reg_rtx (SImode); >> > + aarch64_expand_mov_immediate (tmp, GEN_INT (ival)); >> > + tmp = simplify_gen_subreg (HImode, tmp, SImode, 0); >> > + emit_move_insn (operands[0], gen_lowpart (HFmode, tmp)); >> > + DONE; >> > + }" >> > + [(set_attr "type" "neon_move,f_mcr,neon_to_gp,neon_move,fconsts, >> \ >> > + neon_move,f_loads,f_stores,load1,store1,mov_reg") >> > + (set_attr "simd" "yes,*,yes,yes,*,yes,*,*,*,*,*")] >> > ) >> >> Thanks, >> James >