> -----Original Message----- > From: Stam Markianos-Wright <stam.markianos-wri...@arm.com> > Sent: Wednesday, May 17, 2023 2:41 PM > To: Kyrylo Tkachov <kyrylo.tkac...@arm.com>; gcc-patches@gcc.gnu.org > Cc: Richard Earnshaw <richard.earns...@arm.com>; Andrea Corallo > <andrea.cora...@arm.com> > Subject: [GCC12 backport] arm: MVE testsuite and backend bugfixes > > > On 17/05/2023 10:26, Kyrylo Tkachov wrote: > > Hi Stam, > > > >> -----Original Message----- > >> From: Stam Markianos-Wright <stam.markianos-wri...@arm.com> > >> Sent: Tuesday, May 16, 2023 2:32 PM > >> To: gcc-patches@gcc.gnu.org > >> Cc: Kyrylo Tkachov <kyrylo.tkac...@arm.com>; Richard Earnshaw > >> <richard.earns...@arm.com>; Andrea Corallo > <andrea.cora...@arm.com> > >> Subject: [GCC12 backport] arm: MVE testsuite and backend bugfixes > >> > >> Hi all, > >> > >> We've recently sent up a lot of patches overhauling the testsuite of the > >> Arm MVE backend. > >> With these changes, we've also identified and fixed a number of bugs > >> (some backend bugs and many to do with the polymorphism of intrinsics > in > >> MVE the header file). > >> These would all be relevant to backport to GCC12. > >> The list is as follows (in the order they all apply on top of eachother): > >> > >> * This patch series: > >> https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606552.html > >> (commits 9a79b522e0663a202a288db56ebcbdcdb48bdaca to > >> f2b54e5b796b00f0072b61f9cd6a964c66ead29b) > >> * ecc363971aeac52481d92de8b37521f6cc2d38e6 arm: Fix MVE testsuite > >> fallouts > >> * 06aa66af7d0dacc1b247d9e38175e789ef159191 arm: Add missing early > >> clobber to MVE vrev64q_m patterns > >> * c09663eabfb84ac56ddd8d44abcab3f4902c83bd testsuite: [arm] Relax > >> expected register names in MVE tests > >> * 330d665ce6dcc63ed0bd78d807e69bbfc55255b6 arm: [MVE] Add missing > >> length=8 attribute > >> * 8d4f007398bc3f8fea812fb8cff4d7d0556d12f1 arm: fix mve intrinsics scan > >> body tests for C++ > >> * This patch series > >> https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610312.html > >> (commits dd4424ef898608321b60610c4f3c98737ace3680 to > >> 267f01a493ab8a0bec9325ce3386b946c46f2e98) > >> * 8a1360e72d6c6056606aa5edd8c906c50f26de59 arm: Split up MVE > _Generic > >> associations to prevent type clashes [PR107515] > >> * 3f0ca7a3e4431534bff3b8eb73709cc822e489b0 arm: Fix vcreate > definition > >> * c1093923733a1072a237f112e3239b5ebd88eadd arm: Make MVE > masked > >> stores > >> read memory operand [PR 108177] > >> * f54e31ddefe3ea7146624eabcb75b1c90dc59f1a arm: fix __arm_vld1q_z* > >> and > >> __arm_vst1q_p* intrinsics [PR108442] > >> * 1d509f190393627cffffdf0afffc427b25dd21c2 arm: remove unused > variables > >> from test > >> > > Ok to backport. > > > >> -- up to this point everything applied cleanly. The final two need minor > >> rebasing changes -- > >> > >> * This patch series: > >> https://gcc.gnu.org/pipermail/gcc-patches/2023-April/617008.html (Not > >> pushed to trunk yet, but has been approved. For trunk we do now need to > >> resolve some merge conflicts, since Christophe has started merging the > >> MVE Intrinsic Restructuring, but these are trivial. I will also backport > >> to GCC13 where this patch series applies cleanly) > >> * cfa118fc089e38a94ec60ccf5b667aea015e5f60 [arm] complete vmsr/vmrs > >> blank and case adjustments. > >> > >> The final one is a commit from Alexandre Oliva that is needed to ensure > >> that we don't accidentally regress the test due to the tabs vs spaces > >> and capitalisation on the vmrs/vmsr instructions :) > >> > >> After all that, no regressions on baremetal arm-none-eabi in a bunch > >> configurations (-marm, thumb1, thumb2, MVE, MVE.FP, softfp and hardfp): > >> > > Will you be sending these to the list after adjusting? > > Yep, I believe we have to! > > I'm thinking we should do one batch of [committed] emails for GCC12 and > one for trunk.
Sounds good. > > For GCC13 the previously sent version of the series at > https://gcc.gnu.org/pipermail/gcc-patches/2023-May/617373.html applies > cleanly. Let me know if there's anything further we need to do! > WFM, please go ahead. Thanks, Kyrill > Thanks, > Stamatis > > > > Thanks, > > Kyrill > > > >> Thanks, > >> Stam
