Re: [PATCH] aarch64: Add SVE instruction types

[Evandro Menezes <ebahapo@icloud.com>]

[-- Attachment #1: Type: text/plain, Size: 5381 bytes --]

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 <Kyrylo.Tkachov@arm.com> 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 <ebahapo@icloud.com> 
> Sent: Monday, May 15, 2023 9:13 PM
> To: Kyrylo Tkachov <Kyrylo.Tkachov@arm.com>
> Cc: Richard Sandiford <Richard.Sandiford@arm.com>; Evandro Menezes via Gcc-patches <gcc-patches@gcc.gnu.org>; evandro+gcc@gcc.gnu.org; Tamar Christina <Tamar.Christina@arm.com>
> 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 <Kyrylo.Tkachov@arm.com <mailto:Kyrylo.Tkachov@arm.com>> escreveu:
>  
> 
> 
> 
> -----Original Message-----
> From: Richard Sandiford <richard.sandiford@arm.com <mailto:richard.sandiford@arm.com>>
> Sent: Monday, May 15, 2023 10:01 AM
> To: Evandro Menezes via Gcc-patches <gcc-patches@gcc.gnu.org <mailto:gcc-patches@gcc.gnu.org>>
> Cc: evandro+gcc@gcc.gnu.org <mailto:evandro+gcc@gcc.gnu.org>; Evandro Menezes <ebahapo@icloud.com <mailto:ebahapo@icloud.com>>;
> Kyrylo Tkachov <Kyrylo.Tkachov@arm.com <mailto:Kyrylo.Tkachov@arm.com>>; Tamar Christina
> <Tamar.Christina@arm.com <mailto:Tamar.Christina@arm.com>>
> Subject: Re: [PATCH] aarch64: Add SVE instruction types
> 
> Evandro Menezes via Gcc-patches <gcc-patches@gcc.gnu.org <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
>