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@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 > escreveu: -----Original Message----- From: Richard Sandiford > Sent: Monday, May 15, 2023 10:01 AM To: Evandro Menezes via Gcc-patches > Cc: evandro+gcc@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