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