From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ci74p00im-qukt09090302.me.com (ci74p00im-qukt09090302.me.com [17.57.156.21]) by sourceware.org (Postfix) with ESMTPS id CF9C2385DC35 for ; Wed, 13 Sep 2023 00:54:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CF9C2385DC35 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=icloud.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=icloud.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1694566482; bh=hoGtsYcm66Ex1EhHExEhXLG/hSL5z/Ak9CL21uzoqkM=; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To; b=aTZiZsWtTjFAn+861BBfzvtTo0byeuce74Ogk0G00seelQjwpLWcfac891FwmYvvg sdMHBiLUdEsNLi7oibiSVOawaVc2ms9oK33ohNwgdzvmzSZtC6Nxe03YYYzevPO6FR KV2zO63nY5vDKLLHDWr7iN8/QyIQ0Fe0lsTUnZZP2BZuy5atkp7nY1cHuD6QS9XYxb LUBUDxrwK01T4ZijRIQJm2rbD12HTDFyYSEXJYsMebCF1O8Az8L2CSNE+pDqUgBIZU hOP6bOzB8df5LuR9Fcn7Ym2IXzObrBWWQhNXaUGS1lWfWhdOPLtTu3IcYdXpKs6wNa gvE8Z3RJeXj3g== Received: from smtpclient.apple (ci77p00im-dlb-asmtp-mailmevip.me.com [17.57.156.26]) by ci74p00im-qukt09090302.me.com (Postfix) with ESMTPSA id E2B0F5BC01E5; Wed, 13 Sep 2023 00:54:40 +0000 (UTC) From: Evandro Menezes Message-Id: <2A544AF3-7F97-4606-9D60-2FC625A9DEEB@icloud.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_D4921FE6-7874-43EF-8A64-BFF1D76F0BB6" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: [PATCH] aarch64: Add SVE instruction types Date: Tue, 12 Sep 2023 19:54:09 -0500 In-Reply-To: Cc: Richard Sandiford , Evandro Menezes via Gcc-patches , "evandro+gcc@gcc.gnu.org" , Tamar Christina , Ramana Radhakrishnan To: Kyrylo Tkachov References: <1D567E08-9EBB-4EF7-9626-BA95D8E0EB36@icloud.com> <691ED2DC-333C-4E3D-AB54-B84519673C75@icloud.com> X-Mailer: Apple Mail (2.3731.700.6) X-Proofpoint-ORIG-GUID: KZdhsmY2NhnM4lmtQmOWI1l0-pFRvI8C X-Proofpoint-GUID: KZdhsmY2NhnM4lmtQmOWI1l0-pFRvI8C X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?= =?UTF-8?Q?2903e8d5c8f:6.0.425,18.0.572,17.0.605.474.0000000_definitions?= =?UTF-8?Q?=3D2022-01-11=5F01:2022-01-11=5F01,2020-02-14=5F11,2020-01-23?= =?UTF-8?Q?=5F02_signatures=3D0?= X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 phishscore=0 bulkscore=0 clxscore=1011 suspectscore=0 malwarescore=0 spamscore=0 mlxscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2309130005 X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,KAM_SHORT,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --Apple-Mail=_D4921FE6-7874-43EF-8A64-BFF1D76F0BB6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Kyrill. I wonder if the regression that you noticed was the same that I did. Overa= ll, thus far, there=E2=80=99s no significant regression that I can say is d= ue to scheduling. However, there is one benchmark, 507.cactuBSSN_r/607.cac= tuBSSN_s in SPEC2017, that regressed by more than 10%. Upon closer examina= tion, 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 thoug= h, as there seem to be enough free registers available.=20=20 Is this similar to what you observed as well? I tried to adjust the priori= ty of memory ops through, TARGET_SCHED_ADJUST_PRIORITY, but it was innefect= ive. I=E2=80=99m a bit at a loss what=E2=80=99s likely going on with the R= A at this point. Any pointers? Thank you, --=20 Evandro Menezes > Em 16 de mai. de 2023, =C3=A0(s) 03:36, Kyrylo Tkachov escreveu: >=20 > Hi Evandro, >=20=20 > I created a new attribute so I didn=E2=80=99t have to extend the =E2=80= =9Ctype=E2=80=9D attribute that lives in config/arm/types.md. As that attri= bute and file lives in the arm backend but SVE is AArch64-only I didn=E2=80= =99t want to add logic to the arm backend as it=E2=80=99s not truly shared. > The granularity has been somewhat subjective. I had looked at the Softwar= e Optimisation guides for various SVE and SVE2-capable cores from Arm on de= veloper.arm.com and tried to glean commonalities between different instruct= ion groups. > I did try writing a model for Neoverse V1 using that classification but I= couldn=E2=80=99t spend much time on it and the resulting model didn=E2=80= =99t give me much improvements and gave some regressions instead. > I think that was more down to my rushed model rather than anything else t= hough. >=20=20 > Thanks, > Kyrill >=20=20 > From: Evandro Menezes =20 > Sent: Monday, May 15, 2023 9:13 PM > To: Kyrylo Tkachov > Cc: Richard Sandiford ; Evandro Menezes via Gc= c-patches ; evandro+gcc@gcc.gnu.org; Tamar Christi= na > Subject: Re: [PATCH] aarch64: Add SVE instruction types >=20=20 > Hi, Kyrill. >=20=20 > I wasn=E2=80=99t 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=E2=80=99d lik= e to use them. >=20=20 > Do you have specific examples which you might want to mention with regard= s to granularity? >=20=20 > Yes, my intent for this patch is to enable modeling the SVE instructions = on N1. The patch that implements it brings up some performance improvement= s, but it=E2=80=99s mostly flat, as expected. >=20=20 > Thank you, >=20 > --=20 > Evandro Menezes >=20=20 >=20=20 >=20 >=20 > Em 15 de mai. de 2023, =C3=A0(s) 04:49, Kyrylo Tkachov > escreveu: >=20=20 >=20 >=20 >=20 > -----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 Men= ezes >; > Kyrylo Tkachov >; = Tamar Christina > > > Subject: Re: [PATCH] aarch64: Add SVE instruction types >=20 > Evandro Menezes via Gcc-patches > writes: >=20 > This patch adds the attribute `type` to most SVE1 instructions, as in the > other >=20 > instructions. >=20 > Thanks for doing this. >=20 > 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: >=20 > (a) a scheduling description really needs to distinguish them or > (b) grouping them together would be very artificial (because they're > logically unrelated) >=20 > 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. >=20 > 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. >=20 > I agree with Richard on these points. The key here is getting the granula= rity 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 f= or 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 im= provement on SVE code when combined with the scheduling attributes somehow? > Thanks, > Kyrill >=20=20 --Apple-Mail=_D4921FE6-7874-43EF-8A64-BFF1D76F0BB6--