Message ID | CAE65F3NRLL_jjU45A4BZbFy-xB01q65eGky1tezC_Z9i_7oLzw@mail.gmail.com |
---|---|
State | New |
Headers | show |
Mariam Arutunian <mariamarutunian@gmail.com> writes: > Hello, > > This patch series is a revised version of the following: > https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668229.html. > > In this version: > > - Patch 09/12 has been updated with comments provided by Matevos, which > were missing in the previously submitted series. > - Patch 06/12 includes the following change made by Richard Sandiford, > which is necessary for the code to compile and hasn't been added to the GCC > master branch. > > --- a/gcc/config/aarch64/aarch64-simd.md > +++ b/gcc/config/aarch64/aarch64-simd.md > @@ -4312,7 +4312,7 @@ > ;; RTL uses GCC vector extension indices throughout so flip only for > assembly. > ;; Extracting lane zero is split into a simple move when it is between SIMD > ;; registers or a store. > -(define_insn_and_split "aarch64_get_lane<mode>" > +(define_insn_and_split "@aarch64_get_lane<mode>" > [(set (match_operand:<VEL> 0 "aarch64_simd_nonimmediate_operand" "=?r, w, > Utv") > (vec_select:<VEL> > (match_operand:VALL_F16 1 "register_operand" "w, w, w") > Oops, sorry, I misread this and thought that you were waiting for the above to go in before pushing the aarch64 changes. I now realise that that wasn't the case, but only after I'd tested the below on aarch64-linux-gnu & pushed to trunk. The OK for the aarch64 changes [https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661047.html] still stands. Let me know if you'd like me to test & push the changes. Thanks again for doing this. Richard gcc/ * config/aarch64/aarch64-simd.md (aarch64_get_lane<mode>): Add "@" to the name. --- gcc/config/aarch64/aarch64-simd.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/config/aarch64/aarch64-simd.md b/gcc/config/aarch64/aarch64-simd.md index 05cbd38372d..fd6965d9e86 100644 --- a/gcc/config/aarch64/aarch64-simd.md +++ b/gcc/config/aarch64/aarch64-simd.md @@ -4357,7 +4357,7 @@ (define_insn "*aarch64_get_lane_zero_extend<GPI:mode><VDQQH:mode>" ;; RTL uses GCC vector extension indices throughout so flip only for assembly. ;; Extracting lane zero is split into a simple move when it is between SIMD ;; registers or a store. -(define_insn_and_split "aarch64_get_lane<mode>" +(define_insn_and_split "@aarch64_get_lane<mode>" [(set (match_operand:<VEL> 0 "aarch64_simd_nonimmediate_operand" "=?r, w, Utv") (vec_select:<VEL> (match_operand:VALL_F16 1 "register_operand" "w, w, w")
On 12/9/24 10:00 AM, Richard Sandiford wrote: > Mariam Arutunian <mariamarutunian@gmail.com> writes: >> Hello, >> >> This patch series is a revised version of the following: >> https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668229.html. >> >> In this version: >> >> - Patch 09/12 has been updated with comments provided by Matevos, which >> were missing in the previously submitted series. >> - Patch 06/12 includes the following change made by Richard Sandiford, >> which is necessary for the code to compile and hasn't been added to the GCC >> master branch. >> >> --- a/gcc/config/aarch64/aarch64-simd.md >> +++ b/gcc/config/aarch64/aarch64-simd.md >> @@ -4312,7 +4312,7 @@ >> ;; RTL uses GCC vector extension indices throughout so flip only for >> assembly. >> ;; Extracting lane zero is split into a simple move when it is between SIMD >> ;; registers or a store. >> -(define_insn_and_split "aarch64_get_lane<mode>" >> +(define_insn_and_split "@aarch64_get_lane<mode>" >> [(set (match_operand:<VEL> 0 "aarch64_simd_nonimmediate_operand" "=?r, w, >> Utv") >> (vec_select:<VEL> >> (match_operand:VALL_F16 1 "register_operand" "w, w, w") >> > > Oops, sorry, I misread this and thought that you were waiting for > the above to go in before pushing the aarch64 changes. I now realise > that that wasn't the case, but only after I'd tested the below on > aarch64-linux-gnu & pushed to trunk. > > The OK for the aarch64 changes > [https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661047.html] > still stands. Let me know if you'd like me to test & push the changes. > > Thanks again for doing this. Thanks. I was just about to reach out to confirm we're OK on aarch64. I was going to run everything through one of the cfarm machines or perhaps my rpi as a final test. Jeff
Jeff Law <jeffreyalaw@gmail.com> writes: > On 12/9/24 10:00 AM, Richard Sandiford wrote: >> Mariam Arutunian <mariamarutunian@gmail.com> writes: >>> Hello, >>> >>> This patch series is a revised version of the following: >>> https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668229.html. >>> >>> In this version: >>> >>> - Patch 09/12 has been updated with comments provided by Matevos, which >>> were missing in the previously submitted series. >>> - Patch 06/12 includes the following change made by Richard Sandiford, >>> which is necessary for the code to compile and hasn't been added to the GCC >>> master branch. >>> >>> --- a/gcc/config/aarch64/aarch64-simd.md >>> +++ b/gcc/config/aarch64/aarch64-simd.md >>> @@ -4312,7 +4312,7 @@ >>> ;; RTL uses GCC vector extension indices throughout so flip only for >>> assembly. >>> ;; Extracting lane zero is split into a simple move when it is between SIMD >>> ;; registers or a store. >>> -(define_insn_and_split "aarch64_get_lane<mode>" >>> +(define_insn_and_split "@aarch64_get_lane<mode>" >>> [(set (match_operand:<VEL> 0 "aarch64_simd_nonimmediate_operand" "=?r, w, >>> Utv") >>> (vec_select:<VEL> >>> (match_operand:VALL_F16 1 "register_operand" "w, w, w") >>> >> >> Oops, sorry, I misread this and thought that you were waiting for >> the above to go in before pushing the aarch64 changes. I now realise >> that that wasn't the case, but only after I'd tested the below on >> aarch64-linux-gnu & pushed to trunk. >> >> The OK for the aarch64 changes >> [https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661047.html] >> still stands. Let me know if you'd like me to test & push the changes. >> >> Thanks again for doing this. > Thanks. I was just about to reach out to confirm we're OK on aarch64. > I was going to run everything through one of the cfarm machines or > perhaps my rpi as a final test. Ah, yeah. I'm hopelessly behind on gcc-patches, so hadn't seen that you were applying the series gradually. I've now pushed patches 6 and 7 to trunk after testing on aarch64-linux-gnu. Thanks, Richard
On 12/9/24 3:43 PM, Richard Sandiford wrote: >> Thanks. I was just about to reach out to confirm we're OK on aarch64. >> I was going to run everything through one of the cfarm machines or >> perhaps my rpi as a final test. > > Ah, yeah. I'm hopelessly behind on gcc-patches, so hadn't seen that > you were applying the series gradually. > > I've now pushed patches 6 and 7 to trunk after testing on aarch64-linux-gnu. Thanks a ton for that and with helping Mariam on the aarch64 implementation. Just x86 left ;-) I'll give those another looksie sometime this week and sync with the x86 maintainers to ensure they don't have any concerns. At which point we're done! jeff
Thank you all very much for your help! ) Mariam On Tue, Dec 10, 2024, 04:04 Jeff Law <jeffreyalaw@gmail.com> wrote: > > > On 12/9/24 3:43 PM, Richard Sandiford wrote: > > >> Thanks. I was just about to reach out to confirm we're OK on aarch64. > >> I was going to run everything through one of the cfarm machines or > >> perhaps my rpi as a final test. > > > > Ah, yeah. I'm hopelessly behind on gcc-patches, so hadn't seen that > > you were applying the series gradually. > > > > I've now pushed patches 6 and 7 to trunk after testing on > aarch64-linux-gnu. > Thanks a ton for that and with helping Mariam on the aarch64 > implementation. > > Just x86 left ;-) I'll give those another looksie sometime this week > and sync with the x86 maintainers to ensure they don't have any > concerns. At which point we're done! > > jeff > >
--- a/gcc/config/aarch64/aarch64-simd.md +++ b/gcc/config/aarch64/aarch64-simd.md @@ -4312,7 +4312,7 @@ ;; RTL uses GCC vector extension indices throughout so flip only for assembly. ;; Extracting lane zero is split into a simple move when it is between SIMD ;; registers or a store. -(define_insn_and_split "aarch64_get_lane<mode>" +(define_insn_and_split "@aarch64_get_lane<mode>" [(set (match_operand:<VEL> 0 "aarch64_simd_nonimmediate_operand" "=?r, w, Utv")