On Thu, Jul 28, 2016 at 12:37 PM, Ramana Radhakrishnan <ramana....@googlemail.com> wrote: > On Mon, Jul 4, 2016 at 3:02 PM, Matthew Wahab > <matthew.wa...@foss.arm.com> wrote: >> On 19/05/16 15:54, Matthew Wahab wrote: >>> On 18/05/16 16:20, Joseph Myers wrote: >>>> On Wed, 18 May 2016, Matthew Wahab wrote: >>>> >>>> In short: instructions for direct HFmode arithmetic should be described >>>> with patterns with the standard names. It's the job of the >>>> architecture-independent compiler to ensure that fp16 arithmetic in the >>>> user's source code only generates direct fp16 arithmetic in GIMPLE (and >>>> thus ends up using those patterns) if that is a correct representation of >>>> the source code's semantics according to ACLE. >>>> >>>> The intrinsics you provide can then be written to use direct arithmetic, >>>> and rely on convert_to_real_1 eliminating the promotions, rather than >>>> needing built-in functions at all, just like many arm_neon.h intrinsics >>>> make direct use of GNU C vector arithmetic. >>> >>> I think it's clear that this has exhausted my knowledge of FP semantics. >>> >>> Forcing promotion to single-precision was to settle concerns brought up in >>> internal discussions about __fp16 semantics. I'll see if anybody has any >>> problem with the changes you suggest. >> >> This patch changes the implementation to use the standard names for the >> HFmode arithmetic. Later patches will also be updated to use the >> arithmetic operators where appropriate. >> >> Changes since the last version of this patch: >> - The standard names for plus, minus, mult, div and fma are defined for >> HF mode. >> - The patterns supporting the new ACLE intrinsics vnegh_f16, vaddh_f16, >> vsubh_f16, vmulh_f16 and vdivh_f16 are removed, the arithmetic >> operators will be used instead. >> - The tests are updated to expect f16 instructions rather than the f32 >> instructions that were previously emitted. >> >> Tested the series for arm-none-linux-gnueabihf with native bootstrap and >> make check and for arm-none-eabi and armeb-none-eabi with make check on >> an ARMv8.2-A emulator. > > > All fine except - > > Why can we not extend the <vrint_pattern> and the l<vrint_pattern> in > vfp.md for fp16 and avoid all the unspecs for vcvta and vrnd* > instructions ? >
I now feel reasonably convinced that these can go away and be replaced by extending the <vrint_pattern> and l<vrint_pattern> expanders to consider FP16 as well. Given that we are still only in the middle of stage1 - I'm ok for you to apply this as is and then follow-up with a patch that gets rid of the UNSPECs . If this holds for add, sub and other patterns I don't see why it wouldn't hold for all these patterns as well. Joseph, do you have any opinions on whether we should be extending the standard pattern names or not for btrunc, ceil, round, floor, nearbyint, rint, lround, lfloor and lceil optabs for the HFmode quantities ? Thanks, Ramana > Ramana > > > > >> >> Ok for trunk? >> Matthew >> >> 2016-07-04 Matthew Wahab <matthew.wa...@arm.com> >> >> * config/arm/iterators.md (Code iterators): Fix some white-space >> in the comments. >> (GLTE): New. >> (ABSNEG): New >> (FCVT): Moved from vfp.md. >> (VCVT_HF_US_N): New. >> (VCVT_SI_US_N): New. >> (VCVT_HF_US): New. >> (VCVTH_US): New. >> (FP16_RND): New. >> (absneg_str): New. >> (FCVTI32typename): Moved from vfp.md. >> (sup): Add UNSPEC_VCVTA_S, UNSPEC_VCVTA_U, UNSPEC_VCVTM_S, >> UNSPEC_VCVTM_U, UNSPEC_VCVTN_S, UNSPEC_VCVTN_U, UNSPEC_VCVTP_S, >> UNSPEC_VCVTP_U, UNSPEC_VCVT_HF_S_N, UNSPEC_VCVT_HF_U_N, >> UNSPEC_VCVT_SI_S_N, UNSPEC_VCVT_SI_U_N, UNSPEC_VCVTH_S_N, >> UNSPEC_VCVTH_U_N, UNSPEC_VCVTH_S and UNSPEC_VCVTH_U. >> >> (vcvth_op): New. >> (fp16_rnd_str): New. >> (fp16_rnd_insn): New. > > >> * config/arm/unspecs.md (UNSPEC_VCVT_HF_S_N): New. >> (UNSPEC_VCVT_HF_U_N): New. >> (UNSPEC_VCVT_SI_S_N): New. >> (UNSPEC_VCVT_SI_U_N): New. >> (UNSPEC_VCVTH_S): New. >> (UNSPEC_VCVTH_U): New. >> (UNSPEC_VCVTA_S): New. >> (UNSPEC_VCVTA_U): New. >> (UNSPEC_VCVTM_S): New. >> (UNSPEC_VCVTM_U): New. >> (UNSPEC_VCVTN_S): New. >> (UNSPEC_VCVTN_U): New. >> (UNSPEC_VCVTP_S): New. >> (UNSPEC_VCVTP_U): New. >> (UNSPEC_VCVTP_S): New. >> (UNSPEC_VCVTP_U): New. >> (UNSPEC_VRND): New. >> (UNSPEC_VRNDA): New. >> (UNSPEC_VRNDI): New. >> (UNSPEC_VRNDM): New. >> (UNSPEC_VRNDN): New. >> (UNSPEC_VRNDP): New. >> (UNSPEC_VRNDX): New. >> * config/arm/vfp.md (<absneg_str>hf2): New. >> (neon_vabshf): New. >> (neon_v<fp16_rnd_str>hf): New. >> (neon_vrndihf): New. >> (addhf3): New. >> (subhf3): New. >> (divhf3): New. >> (mulhf3): New. >> (*mulsf3neghf_vfp): New. >> (*negmulhf3_vfp): New. >> (*mulsf3addhf_vfp): New. >> (*mulhf3subhf_vfp): New. >> (*mulhf3neghfaddhf_vfp): New. >> (*mulhf3neghfsubhf_vfp): New. >> (fmahf4): New. >> (neon_vfmahf): New. >> (fmsubhf4_fp16): New. >> (neon_vfmshf): New. >> (*fnmsubhf4): New. >> (*fnmaddhf4): New. >> (neon_vsqrthf): New. >> (neon_vrsqrtshf): New. >> (FCVT): Move to iterators.md. >> (FCVTI32typename): Likewise. >> (neon_vcvth<sup>hf): New. >> (neon_vcvth<sup>si): New. >> (neon_vcvth<sup>_nhf_unspec): New. >> (neon_vcvth<sup>_nhf): New. >> (neon_vcvth<sup>_nsi_unspec): New. >> (neon_vcvth<sup>_nsi): New. >> (neon_vcvt<vcvth_op>h<sup>si): New. >> (neon_<fmaxmin_op>hf): New. >> >> testsuite/ >> 2016-07-04 Matthew Wahab <matthew.wa...@arm.com> >> >> >> * gcc.target/arm/armv8_2-fp16-arith-1.c: New. >> * gcc.target/arm/armv8_2-fp16-conv-1.c: New. >>
