Re: [PATCH] aarch64: Add SVE instruction types
Hi, Kyrill. I wonder if the regression that you noticed was the same that I did. Overall, thus far, there’s no significant regression that I can say is due to scheduling. However, there is one benchmark, 507.cactuBSSN_r/607.cactuBSSN_s in SPEC2017, that regressed by more than 10%. Upon closer examination, it seems that the change in the live ranges led to heavy spilling and to doubling of the stack size. The spilling looks rather capricious though, as there seem to be enough free registers available. Is this similar to what you observed as well? I tried to adjust the priority of memory ops through, TARGET_SCHED_ADJUST_PRIORITY, but it was innefective. I’m a bit at a loss what’s likely going on with the RA at this point. Any pointers? Thank you, -- Evandro Menezes > Em 16 de mai. de 2023, à(s) 03:36, Kyrylo Tkachov > escreveu: > > Hi Evandro, > > I created a new attribute so I didn’t have to extend the “type” attribute > that lives in config/arm/types.md. As that attribute and file lives in the > arm backend but SVE is AArch64-only I didn’t want to add logic to the arm > backend as it’s not truly shared. > The granularity has been somewhat subjective. I had looked at the Software > Optimisation guides for various SVE and SVE2-capable cores from Arm on > developer.arm.com and tried to glean commonalities between different > instruction groups. > I did try writing a model for Neoverse V1 using that classification but I > couldn’t spend much time on it and the resulting model didn’t give me much > improvements and gave some regressions instead. > I think that was more down to my rushed model rather than anything else > though. > > Thanks, > Kyrill > > From: Evandro Menezes > Sent: Monday, May 15, 2023 9:13 PM > To: Kyrylo Tkachov > Cc: Richard Sandiford ; Evandro Menezes via > Gcc-patches ; evandro+...@gcc.gnu.org; Tamar > Christina > Subject: Re: [PATCH] aarch64: Add SVE instruction types > > Hi, Kyrill. > > I wasn’t aware of your previous patch. Could you clarify why you considered > creating an SVE specific type attribute instead of reusing the common one? I > really liked the iterators that you created; I’d like to use them. > > Do you have specific examples which you might want to mention with regards to > granularity? > > Yes, my intent for this patch is to enable modeling the SVE instructions on > N1. The patch that implements it brings up some performance improvements, > but it’s mostly flat, as expected. > > Thank you, > > -- > Evandro Menezes > > > > > Em 15 de mai. de 2023, à(s) 04:49, Kyrylo Tkachov <mailto:kyrylo.tkac...@arm.com>> escreveu: > > > > > -Original Message- > From: Richard Sandiford <mailto:richard.sandif...@arm.com>> > Sent: Monday, May 15, 2023 10:01 AM > To: Evandro Menezes via Gcc-patches <mailto:gcc-patches@gcc.gnu.org>> > Cc: evandro+...@gcc.gnu.org <mailto:evandro+...@gcc.gnu.org>; Evandro Menezes > mailto:ebah...@icloud.com>>; > Kyrylo Tkachov mailto:kyrylo.tkac...@arm.com>>; > Tamar Christina > mailto:tamar.christ...@arm.com>> > Subject: Re: [PATCH] aarch64: Add SVE instruction types > > Evandro Menezes via Gcc-patches <mailto:gcc-patches@gcc.gnu.org>> writes: > > This patch adds the attribute `type` to most SVE1 instructions, as in the > other > > instructions. > > Thanks for doing this. > > Could you say what criteria you used for picking the granularity? Other > maintainers might disagree, but personally I'd prefer to distinguish two > instructions only if: > > (a) a scheduling description really needs to distinguish them or > (b) grouping them together would be very artificial (because they're >logically unrelated) > > It's always possible to split types later if new scheduling descriptions > require it. Because of that, I don't think we should try to predict ahead > of time what future scheduling descriptions will need. > > Of course, this depends on having results that show that scheduling > makes a significant difference on an SVE core. I think one of the > problems here is that, when a different scheduling model changes the > performance of a particular test, it's difficult to tell whether > the gain/loss is caused by the model being more/less accurate than > the previous one, or if it's due to important "secondary" effects > on register live ranges. Instinctively, I'd have expected these > secondary effects to dominate on OoO cores. > > I agree with Richard on these points. The key here is getting the granularity > right without having too maintain too many types that aren't useful in the >
Re: [PATCH] aarch64: Add SVE instruction types
Hi, Kyrill. It makes sense. I could add the classification to a different attribute as you did and keep it in aarch64 as well. I took the same approach, gleaning over several optimization guides for Arm processors supporting SVE and figuring out the smallest number of types that could cover most variations of resources used. Methinks that the classification in this patch is close to that goal, but feedback is appreciated. I did observe a meaningful gain in performance. Of course, wide machines like the V1 can handle most instruction sequences thrown at it, but there’s still some efficiency left on the table without a tailored scheduling, especially when recovering from cache or branch misses, when it’s important to quickly fill up the pipeline back to regime, albeit umpteen transistors are dedicated to make sure that misses do not happen often. Thank you, -- Evandro Menezes > Em 16 de mai. de 2023, à(s) 03:36, Kyrylo Tkachov > escreveu: > > Hi Evandro, > > I created a new attribute so I didn’t have to extend the “type” attribute > that lives in config/arm/types.md. As that attribute and file lives in the > arm backend but SVE is AArch64-only I didn’t want to add logic to the arm > backend as it’s not truly shared. > The granularity has been somewhat subjective. I had looked at the Software > Optimisation guides for various SVE and SVE2-capable cores from Arm on > developer.arm.com <http://developer.arm.com/> and tried to glean > commonalities between different instruction groups. > I did try writing a model for Neoverse V1 using that classification but I > couldn’t spend much time on it and the resulting model didn’t give me much > improvements and gave some regressions instead. > I think that was more down to my rushed model rather than anything else > though. > > Thanks, > Kyrill > > From: Evandro Menezes > Sent: Monday, May 15, 2023 9:13 PM > To: Kyrylo Tkachov > Cc: Richard Sandiford ; Evandro Menezes via > Gcc-patches ; evandro+...@gcc.gnu.org; Tamar > Christina > Subject: Re: [PATCH] aarch64: Add SVE instruction types > > Hi, Kyrill. > > I wasn’t aware of your previous patch. Could you clarify why you considered > creating an SVE specific type attribute instead of reusing the common one? I > really liked the iterators that you created; I’d like to use them. > > Do you have specific examples which you might want to mention with regards to > granularity? > > Yes, my intent for this patch is to enable modeling the SVE instructions on > N1. The patch that implements it brings up some performance improvements, > but it’s mostly flat, as expected. > > Thank you, > > -- > Evandro Menezes > > > > > Em 15 de mai. de 2023, à(s) 04:49, Kyrylo Tkachov <mailto:kyrylo.tkac...@arm.com>> escreveu: > > > > > -Original Message- > From: Richard Sandiford <mailto:richard.sandif...@arm.com>> > Sent: Monday, May 15, 2023 10:01 AM > To: Evandro Menezes via Gcc-patches <mailto:gcc-patches@gcc.gnu.org>> > Cc: evandro+...@gcc.gnu.org <mailto:evandro+...@gcc.gnu.org>; Evandro Menezes > mailto:ebah...@icloud.com>>; > Kyrylo Tkachov mailto:kyrylo.tkac...@arm.com>>; > Tamar Christina > mailto:tamar.christ...@arm.com>> > Subject: Re: [PATCH] aarch64: Add SVE instruction types > > Evandro Menezes via Gcc-patches <mailto:gcc-patches@gcc.gnu.org>> writes: > > This patch adds the attribute `type` to most SVE1 instructions, as in the > other > > instructions. > > Thanks for doing this. > > Could you say what criteria you used for picking the granularity? Other > maintainers might disagree, but personally I'd prefer to distinguish two > instructions only if: > > (a) a scheduling description really needs to distinguish them or > (b) grouping them together would be very artificial (because they're >logically unrelated) > > It's always possible to split types later if new scheduling descriptions > require it. Because of that, I don't think we should try to predict ahead > of time what future scheduling descriptions will need. > > Of course, this depends on having results that show that scheduling > makes a significant difference on an SVE core. I think one of the > problems here is that, when a different scheduling model changes the > performance of a particular test, it's difficult to tell whether > the gain/loss is caused by the model being more/less accurate than > the previous one, or if it's due to important "secondary" effects > on register live ranges. Instinctively, I'd have expected these > secondary effects to dominate on OoO cores. > > I agree with Richard
RE: [PATCH] aarch64: Add SVE instruction types
Hi Evandro, I created a new attribute so I didn’t have to extend the “type” attribute that lives in config/arm/types.md. As that attribute and file lives in the arm backend but SVE is AArch64-only I didn’t want to add logic to the arm backend as it’s not truly shared. The granularity has been somewhat subjective. I had looked at the Software Optimisation guides for various SVE and SVE2-capable cores from Arm on developer.arm.com and tried to glean commonalities between different instruction groups. I did try writing a model for Neoverse V1 using that classification but I couldn’t spend much time on it and the resulting model didn’t give me much improvements and gave some regressions instead. I think that was more down to my rushed model rather than anything else though. Thanks, Kyrill From: Evandro Menezes Sent: Monday, May 15, 2023 9:13 PM To: Kyrylo Tkachov Cc: Richard Sandiford ; Evandro Menezes via Gcc-patches ; evandro+...@gcc.gnu.org; Tamar Christina Subject: Re: [PATCH] aarch64: Add SVE instruction types Hi, Kyrill. I wasn’t aware of your previous patch. Could you clarify why you considered creating an SVE specific type attribute instead of reusing the common one? I really liked the iterators that you created; I’d like to use them. Do you have specific examples which you might want to mention with regards to granularity? Yes, my intent for this patch is to enable modeling the SVE instructions on N1. The patch that implements it brings up some performance improvements, but it’s mostly flat, as expected. Thank you, -- Evandro Menezes Em 15 de mai. de 2023, à(s) 04:49, Kyrylo Tkachov mailto:kyrylo.tkac...@arm.com>> escreveu: -Original Message- From: Richard Sandiford mailto:richard.sandif...@arm.com>> Sent: Monday, May 15, 2023 10:01 AM To: Evandro Menezes via Gcc-patches mailto:gcc-patches@gcc.gnu.org>> Cc: evandro+...@gcc.gnu.org<mailto:evandro+...@gcc.gnu.org>; Evandro Menezes mailto:ebah...@icloud.com>>; Kyrylo Tkachov mailto:kyrylo.tkac...@arm.com>>; Tamar Christina mailto:tamar.christ...@arm.com>> Subject: Re: [PATCH] aarch64: Add SVE instruction types Evandro Menezes via Gcc-patches mailto:gcc-patches@gcc.gnu.org>> writes: This patch adds the attribute `type` to most SVE1 instructions, as in the other instructions. Thanks for doing this. Could you say what criteria you used for picking the granularity? Other maintainers might disagree, but personally I'd prefer to distinguish two instructions only if: (a) a scheduling description really needs to distinguish them or (b) grouping them together would be very artificial (because they're logically unrelated) It's always possible to split types later if new scheduling descriptions require it. Because of that, I don't think we should try to predict ahead of time what future scheduling descriptions will need. Of course, this depends on having results that show that scheduling makes a significant difference on an SVE core. I think one of the problems here is that, when a different scheduling model changes the performance of a particular test, it's difficult to tell whether the gain/loss is caused by the model being more/less accurate than the previous one, or if it's due to important "secondary" effects on register live ranges. Instinctively, I'd have expected these secondary effects to dominate on OoO cores. I agree with Richard on these points. The key here is getting the granularity right without having too maintain too many types that aren't useful in the models. FWIW I had posted https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607101.html in November. It adds annotations to SVE2 patterns as well as for base SVE. Feel free to reuse it if you'd like. I see you had posted a Neoverse V1 scheduling model. Does that give an improvement on SVE code when combined with the scheduling attributes somehow? Thanks, Kyrill
Re: [PATCH] aarch64: Add SVE instruction types
Hi, Kyrill. I wasn’t aware of your previous patch. Could you clarify why you considered creating an SVE specific type attribute instead of reusing the common one? I really liked the iterators that you created; I’d like to use them. Do you have specific examples which you might want to mention with regards to granularity? Yes, my intent for this patch is to enable modeling the SVE instructions on N1. The patch that implements it brings up some performance improvements, but it’s mostly flat, as expected. Thank you, -- Evandro Menezes > Em 15 de mai. de 2023, à(s) 04:49, Kyrylo Tkachov > escreveu: > > > >> -Original Message- >> From: Richard Sandiford > <mailto:richard.sandif...@arm.com>> >> Sent: Monday, May 15, 2023 10:01 AM >> To: Evandro Menezes via Gcc-patches > <mailto:gcc-patches@gcc.gnu.org>> >> Cc: evandro+...@gcc.gnu.org <mailto:evandro+...@gcc.gnu.org>; Evandro >> Menezes mailto:ebah...@icloud.com>>; >> Kyrylo Tkachov mailto:kyrylo.tkac...@arm.com>>; >> Tamar Christina >> mailto:tamar.christ...@arm.com>> >> Subject: Re: [PATCH] aarch64: Add SVE instruction types >> >> Evandro Menezes via Gcc-patches writes: >>> This patch adds the attribute `type` to most SVE1 instructions, as in the >> other >>> instructions. >> >> Thanks for doing this. >> >> Could you say what criteria you used for picking the granularity? Other >> maintainers might disagree, but personally I'd prefer to distinguish two >> instructions only if: >> >> (a) a scheduling description really needs to distinguish them or >> (b) grouping them together would be very artificial (because they're >>logically unrelated) >> >> It's always possible to split types later if new scheduling descriptions >> require it. Because of that, I don't think we should try to predict ahead >> of time what future scheduling descriptions will need. >> >> Of course, this depends on having results that show that scheduling >> makes a significant difference on an SVE core. I think one of the >> problems here is that, when a different scheduling model changes the >> performance of a particular test, it's difficult to tell whether >> the gain/loss is caused by the model being more/less accurate than >> the previous one, or if it's due to important "secondary" effects >> on register live ranges. Instinctively, I'd have expected these >> secondary effects to dominate on OoO cores. > > I agree with Richard on these points. The key here is getting the granularity > right without having too maintain too many types that aren't useful in the > models. > FWIW I had posted > https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607101.html in > November. It adds annotations to SVE2 patterns as well as for base SVE. > Feel free to reuse it if you'd like. > I see you had posted a Neoverse V1 scheduling model. Does that give an > improvement on SVE code when combined with the scheduling attributes somehow? > Thanks, > Kyrill
Re: [PATCH] aarch64: Add SVE instruction types
Hi, Richard. My criteria were very much (a). In some cases though, a particular instruction could have variations that others in its natural group didn’t, when if seemed sensible to create a specific description for this instruction, even if its base form shares resources with other instructions in its group. Do you have specific instances in mind? Thank you, -- Evandro Menezes > Em 15 de mai. de 2023, à(s) 04:00, Richard Sandiford > escreveu: > > Evandro Menezes via Gcc-patches writes: >> This patch adds the attribute `type` to most SVE1 instructions, as in the >> other >> instructions. > > Thanks for doing this. > > Could you say what criteria you used for picking the granularity? Other > maintainers might disagree, but personally I'd prefer to distinguish two > instructions only if: > > (a) a scheduling description really needs to distinguish them or > (b) grouping them together would be very artificial (because they're >logically unrelated) > > It's always possible to split types later if new scheduling descriptions > require it. Because of that, I don't think we should try to predict ahead > of time what future scheduling descriptions will need. > > Of course, this depends on having results that show that scheduling > makes a significant difference on an SVE core. I think one of the > problems here is that, when a different scheduling model changes the > performance of a particular test, it's difficult to tell whether > the gain/loss is caused by the model being more/less accurate than > the previous one, or if it's due to important "secondary" effects > on register live ranges. Instinctively, I'd have expected these > secondary effects to dominate on OoO cores. > > Richard -- Evandro Menezes ◊ evan...@yahoo.com ◊ Austin, TX Άγιος ο Θεός ⁂ ܩܕܝܫܐ ܐܢ̱ܬ ܠܐ ܡܝܘܬܐ ⁂ Sanctus Deus
RE: [PATCH] aarch64: Add SVE instruction types
> -Original Message- > From: Richard Sandiford > Sent: Monday, May 15, 2023 10:01 AM > To: Evandro Menezes via Gcc-patches > Cc: evandro+...@gcc.gnu.org; Evandro Menezes ; > Kyrylo Tkachov ; Tamar Christina > > Subject: Re: [PATCH] aarch64: Add SVE instruction types > > Evandro Menezes via Gcc-patches writes: > > This patch adds the attribute `type` to most SVE1 instructions, as in the > other > > instructions. > > Thanks for doing this. > > Could you say what criteria you used for picking the granularity? Other > maintainers might disagree, but personally I'd prefer to distinguish two > instructions only if: > > (a) a scheduling description really needs to distinguish them or > (b) grouping them together would be very artificial (because they're > logically unrelated) > > It's always possible to split types later if new scheduling descriptions > require it. Because of that, I don't think we should try to predict ahead > of time what future scheduling descriptions will need. > > Of course, this depends on having results that show that scheduling > makes a significant difference on an SVE core. I think one of the > problems here is that, when a different scheduling model changes the > performance of a particular test, it's difficult to tell whether > the gain/loss is caused by the model being more/less accurate than > the previous one, or if it's due to important "secondary" effects > on register live ranges. Instinctively, I'd have expected these > secondary effects to dominate on OoO cores. I agree with Richard on these points. The key here is getting the granularity right without having too maintain too many types that aren't useful in the models. FWIW I had posted https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607101.html in November. It adds annotations to SVE2 patterns as well as for base SVE. Feel free to reuse it if you'd like. I see you had posted a Neoverse V1 scheduling model. Does that give an improvement on SVE code when combined with the scheduling attributes somehow? Thanks, Kyrill > > Richard > > > > > -- > > Evandro Menezes > > > > > > > > From be61df66d1a86bc7ec415eb23504002831c67c51 Mon Sep 17 00:00:00 > 2001 > > From: Evandro Menezes > > Date: Mon, 8 May 2023 17:39:10 -0500 > > Subject: [PATCH 2/3] aarch64: Add SVE instruction types > > > > gcc/ChangeLog: > > > > * config/aarch64/aarch64-sve.md: Use the instruction types. > > * config/arm/types.md: (sve_loop_p, sve_loop_ps, sve_loop_gs, > > sve_loop_end, sve_logic_p, sve_logic_ps, sve_cnt_p, > > sve_cnt_pv, sve_cnt_pvx, sve_rev_p, sve_sel_p, sve_set_p, > > sve_set_ps, sve_trn_p, sve_upk_p, sve_zip_p, sve_arith, > > sve_arith_r, sve_arith_sat, sve_arith_sat_x, sve_arith_x, > > sve_logic, sve_logic_r, sve_logic_x, sve_shift, sve_shift_d, > > sve_shift_dx, sve_shift_x, sve_compare_s, sve_cnt, sve_cnt_x, > > sve_copy, sve_copy_g, sve_move, sve_move_x, sve_move_g, > > sve_permute, sve_splat, sve_splat_m, sve_splat_g, sve_cext, > > sve_cext_x, sve_cext_g, sve_ext, sve_ext_x, sve_sext, > > sve_sext_x, sve_uext, sve_uext_x, sve_index, sve_index_g, > > sve_ins, sve_ins_x, sve_ins_g, sve_ins_gx, sve_rev, sve_rev_x, > > sve_tbl, sve_trn, sve_upk, sve_zip, sve_int_to_fp, > > sve_int_to_fp_x, sve_fp_to_int, sve_fp_to_int_x, sve_fp_to_fp, > > sve_fp_to_fp_x, sve_fp_round, sve_fp_round_x, sve_bf_to_fp, > > sve_bf_to_fp_x, sve_div, sve_div_x, sve_dot, sve_dot_x, > > sve_mla, sve_mla_x, sve_mmla, sve_mmla_x, sve_mul, sve_mul_x, > > sve_prfx, sve_fp_arith, sve_fp_arith_a, sve_fp_arith_c, > > sve_fp_arith_cx, sve_fp_arith_r, sve_fp_arith_x, > > sve_fp_compare, sve_fp_copy, sve_fp_move, sve_fp_move_x, > > sve_fp_div_d, sve_fp_div_dx, sve_fp_div_s, sve_fp_div_sx > > sve_fp_dot, sve_fp_mla, sve_fp_mla_x, sve_fp_mla_c, > > sve_fp_mla_cx, sve_fp_mla_t, sve_fp_mla_tx, sve_fp_mmla, > > sve_fp_mmla_x, sve_fp_mul, sve_fp_mul_x, sve_fp_sqrt_d, > > sve_fp_sqrt_dx, sve_fp_sqrt_s, sve_fp_sqrt_sx, sve_fp_trig, > > sve_fp_trig_x, sve_fp_estimate, sve_fp_step, sve_bf_dot, > > sve_bf_dot_x, sve_bf_mla, sve_bf_mla_x, sve_bf_mmla, > > sve_bf_mmla_x, sve_ldr, sve_ldr_p, sve_load1, > > sve_load1_gather_d, sve_load1_gather_dl, sve_load1_gather_du, > > sve_load1_gather_s, sve_load1_gather_sl, sve_load1_gather_su, > > sve_load2, sve_load3, sve_load4, sve_str, sve_str_p, > > sve_store1, sve_store1_scatter, sve_store2, sve_store3, > &
Re: [PATCH] aarch64: Add SVE instruction types
Evandro Menezes via Gcc-patches writes: > This patch adds the attribute `type` to most SVE1 instructions, as in the > other > instructions. Thanks for doing this. Could you say what criteria you used for picking the granularity? Other maintainers might disagree, but personally I'd prefer to distinguish two instructions only if: (a) a scheduling description really needs to distinguish them or (b) grouping them together would be very artificial (because they're logically unrelated) It's always possible to split types later if new scheduling descriptions require it. Because of that, I don't think we should try to predict ahead of time what future scheduling descriptions will need. Of course, this depends on having results that show that scheduling makes a significant difference on an SVE core. I think one of the problems here is that, when a different scheduling model changes the performance of a particular test, it's difficult to tell whether the gain/loss is caused by the model being more/less accurate than the previous one, or if it's due to important "secondary" effects on register live ranges. Instinctively, I'd have expected these secondary effects to dominate on OoO cores. Richard > > -- > Evandro Menezes > > > > From be61df66d1a86bc7ec415eb23504002831c67c51 Mon Sep 17 00:00:00 2001 > From: Evandro Menezes > Date: Mon, 8 May 2023 17:39:10 -0500 > Subject: [PATCH 2/3] aarch64: Add SVE instruction types > > gcc/ChangeLog: > > * config/aarch64/aarch64-sve.md: Use the instruction types. > * config/arm/types.md: (sve_loop_p, sve_loop_ps, sve_loop_gs, > sve_loop_end, sve_logic_p, sve_logic_ps, sve_cnt_p, > sve_cnt_pv, sve_cnt_pvx, sve_rev_p, sve_sel_p, sve_set_p, > sve_set_ps, sve_trn_p, sve_upk_p, sve_zip_p, sve_arith, > sve_arith_r, sve_arith_sat, sve_arith_sat_x, sve_arith_x, > sve_logic, sve_logic_r, sve_logic_x, sve_shift, sve_shift_d, > sve_shift_dx, sve_shift_x, sve_compare_s, sve_cnt, sve_cnt_x, > sve_copy, sve_copy_g, sve_move, sve_move_x, sve_move_g, > sve_permute, sve_splat, sve_splat_m, sve_splat_g, sve_cext, > sve_cext_x, sve_cext_g, sve_ext, sve_ext_x, sve_sext, > sve_sext_x, sve_uext, sve_uext_x, sve_index, sve_index_g, > sve_ins, sve_ins_x, sve_ins_g, sve_ins_gx, sve_rev, sve_rev_x, > sve_tbl, sve_trn, sve_upk, sve_zip, sve_int_to_fp, > sve_int_to_fp_x, sve_fp_to_int, sve_fp_to_int_x, sve_fp_to_fp, > sve_fp_to_fp_x, sve_fp_round, sve_fp_round_x, sve_bf_to_fp, > sve_bf_to_fp_x, sve_div, sve_div_x, sve_dot, sve_dot_x, > sve_mla, sve_mla_x, sve_mmla, sve_mmla_x, sve_mul, sve_mul_x, > sve_prfx, sve_fp_arith, sve_fp_arith_a, sve_fp_arith_c, > sve_fp_arith_cx, sve_fp_arith_r, sve_fp_arith_x, > sve_fp_compare, sve_fp_copy, sve_fp_move, sve_fp_move_x, > sve_fp_div_d, sve_fp_div_dx, sve_fp_div_s, sve_fp_div_sx > sve_fp_dot, sve_fp_mla, sve_fp_mla_x, sve_fp_mla_c, > sve_fp_mla_cx, sve_fp_mla_t, sve_fp_mla_tx, sve_fp_mmla, > sve_fp_mmla_x, sve_fp_mul, sve_fp_mul_x, sve_fp_sqrt_d, > sve_fp_sqrt_dx, sve_fp_sqrt_s, sve_fp_sqrt_sx, sve_fp_trig, > sve_fp_trig_x, sve_fp_estimate, sve_fp_step, sve_bf_dot, > sve_bf_dot_x, sve_bf_mla, sve_bf_mla_x, sve_bf_mmla, > sve_bf_mmla_x, sve_ldr, sve_ldr_p, sve_load1, > sve_load1_gather_d, sve_load1_gather_dl, sve_load1_gather_du, > sve_load1_gather_s, sve_load1_gather_sl, sve_load1_gather_su, > sve_load2, sve_load3, sve_load4, sve_str, sve_str_p, > sve_store1, sve_store1_scatter, sve_store2, sve_store3, > sve_store4, sve_rd_ffr, sve_rd_ffr_p, sve_rd_ffr_ps, > sve_wr_ffr): New types. > > Signed-off-by: Evandro Menezes > --- > gcc/config/aarch64/aarch64-sve.md | 632 ++ > gcc/config/arm/types.md | 342 > 2 files changed, 819 insertions(+), 155 deletions(-) > > diff --git a/gcc/config/aarch64/aarch64-sve.md > b/gcc/config/aarch64/aarch64-sve.md > index 2898b85376b..58c5cb2ddbc 100644 > --- a/gcc/config/aarch64/aarch64-sve.md > +++ b/gcc/config/aarch64/aarch64-sve.md > @@ -699,6 +699,7 @@ > str\t%1, %0 > mov\t%0.d, %1.d > * return aarch64_output_sve_mov_immediate (operands[1]);" > + [(set_attr "type" "sve_ldr, sve_str, sve_move, *")] > ) > > ;; Unpredicated moves that cannot use LDR and STR, i.e. partial vectors > @@ -714,6 +715,7 @@ >"@ > mov\t%0.d, %1.d > * return aarch64_output_sve_mov_immediate (operands[1]);" > + [(set_attr "type" "sve_move, sve_move_x")] > ) > > ;; Handle memory reloads for modes that can't use LDR and STR. We use > @@ -758,6 +760,8 @@ >"&& register_operand (operands[0], mode) > && register_operand (operands[2], mode)" >[(set (match_dup 0) (match_dup 2))] > + "" > + [(set_attr "type" "sve_load1, sve_store1, *")] > ) > > ;; A pattern for optimizing
[PATCH] aarch64: Add SVE instruction types
This patch adds the attribute `type` to most SVE1 instructions, as in the other instructions. -- Evandro Menezes 0002-aarch64-Add-SVE-instruction-types.patch Description: Binary data
