Andrea Corallo <andrea.cora...@arm.com> writes: > Andrea Corallo via Gcc-patches <gcc-patches@gcc.gnu.org> writes: > >> Hi all, >> >> Second version of the patch here implementing the bfloat16_t neon >> related store intrinsics: vst2_lane_bf16, vst2q_lane_bf16, >> vst3_lane_bf16, vst3q_lane_bf16 vst4_lane_bf16, vst4q_lane_bf16. >> >> Please see refer to: >> ACLE <https://developer.arm.com/docs/101028/latest> >> ISA <https://developer.arm.com/docs/ddi0596/latest> >> >> This better narrows testcases so they do not cause regressions for the >> arm backend where these intrinsics are not yet present. >> >> Please see refer to: >> ACLE <https://developer.arm.com/docs/101028/latest> >> ISA <https://developer.arm.com/docs/ddi0596/latest> >> > > Hi all, > > third version of this patch following the suggestions got for its sister > patch <https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557308.html> > > Regtested and bootstrapped. > > Okay for trunk and 10?
OK, thanks. FTR, I wondered whether bf16_vstN_lane_1.c (being a run test) required a stronger condition than arm_v8_2a_bf16_neon_ok. But it doesn't of course: these particular instructions exist in base Armv8-A and the +bf16 requirement is a software-only thing. Richard
