From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2115.outbound.protection.outlook.com [40.107.21.115]) by sourceware.org (Postfix) with ESMTPS id C22273851527 for ; Fri, 28 Oct 2022 13:39:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C22273851527 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=Syrmia.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=Syrmia.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=J+6AtiJskrLArRATfhew+KCtHbKO/UylISREcduHu/qbXIc9dp3bdJHuIGkbV1LuYifrjeWc23dVqqNCPpK09AyZ5lSwoGAP7nAEgs3QpE3azyTn9VVhLzoyHL1nGiH5xWfKJY0wYw2u3Yn2wleMQY+ji3jKT5sKPr/k/VkOhAmXR2RLEl3X6kNDiKhrp1XreU3fS2HZPtM/hWai1gJNVgTC9+i7XbL5PvuBxky7g/klhuZvHs4WXx0KBngu6GTuw/Hpj4emWX9gY3S4zNf0gPzQfLLzv2EUiNGq0HGVEOGue4Mi8Mlbp3K4EXIHNT26RW8Ar6QLnY6lNdFU7xpAvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=0DYeqfIPdem6kGu72Zh1DCFwpbaBZVtTXHDl0DvKUys=; b=IpfkroLdTub8wzkOpSMIjx/T9KV1FFMuQ+tpoUmeKe6RL2u7ncqbmCKxicFvx1O/EBZJORbzW+hGRW/fxtbk/SYDMwCcifxMJn2C8wuwLVJcDKYqFPG5+gMOdy6c3P/h/FWdYV5xlfXfTsFxrgEzqPlMDEA2XW2kYf+nmJYCl0VHQK3n9UEVtvhPE6CDZ9u69NyWbZbrnzB75g4i5pa8crXvNyzpVhmzpSdJ3tWsWH8wmLm7qwkESzZWTgn+7CXv8UxhiMUcehnDLsgS7QIH/q24ayMdnl7VJXAZ9saVNE4GyGvDDRjV7wq+yFO+j5FqVlJZXlVLRWWsvi5BiqAOVA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=syrmia.com; dmarc=pass action=none header.from=syrmia.com; dkim=pass header.d=syrmia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=syrmia.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0DYeqfIPdem6kGu72Zh1DCFwpbaBZVtTXHDl0DvKUys=; b=fOf2z+bEAKBpe2lXi7P7hct/HgLwzl/7gfDEKgbPJzbSvVEiMb8Wc1y6bRRpmFxVQ0fzb0lEp1Flsn/oov3+1//kB2HWyJVmMp42yCAW5cJqwyvhJYgS4dFqmMLBnCECC9t3cqCol6xAROMImEsfXs+e7ZEpjPsv04Cd64FlZjQ= Received: from AM0PR03MB4882.eurprd03.prod.outlook.com (2603:10a6:208:fb::17) by DU0PR03MB8164.eurprd03.prod.outlook.com (2603:10a6:10:353::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5769.15; Fri, 28 Oct 2022 13:39:06 +0000 Received: from AM0PR03MB4882.eurprd03.prod.outlook.com ([fe80::7f26:4554:fc25:8412]) by AM0PR03MB4882.eurprd03.prod.outlook.com ([fe80::7f26:4554:fc25:8412%3]) with mapi id 15.20.5746.028; Fri, 28 Oct 2022 13:39:06 +0000 From: Dimitrije Milosevic To: Richard Biener CC: Jeff Law , "gcc-patches@gcc.gnu.org" , Djordje Todorovic Subject: Re: [PATCH 1/2] ivopts: Revert computation of address cost complexity. Thread-Topic: [PATCH 1/2] ivopts: Revert computation of address cost complexity. Thread-Index: AQHY5VSpCkpNZ9wRE0qr2B1vutRVJa4i5Z0AgAB9V4aAAAhsgIAAZJuc Date: Fri, 28 Oct 2022 13:39:06 +0000 Message-ID: References: <20221021135203.626255-1-dimitrije.milosevic@syrmia.com> <20221021135203.626255-2-dimitrije.milosevic@syrmia.com> <3c50de1f-c00b-9f8a-a604-a71bc546f1c2@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=Syrmia.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: AM0PR03MB4882:EE_|DU0PR03MB8164:EE_ x-ms-office365-filtering-correlation-id: a4baf80a-0483-488f-09f4-08dab8e9c8e3 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XCV1R/yiDVIlUActWwuUGS4OzuxZobePkNjNli2l1ISoboPlAjGf/8F7KOdC/w6VgoEFn4qTW4qnaXGR6CtGUb3We6mk9wquKuKFkKQamJssE9Oua9lvGkEZZaIihwhxhK+ZcugDctWbqZo0WqPLidzzJ5iAVMpx76G/sIxcj85Gg5NLVM15+qT8Ot3Cr2iyMIns3cZ9/Uvjr7e8lW6GzbOP03xydYpSyJmgctROH/gzx83Eksr4GilgJzsFqQ1fi1RZiufgUWD0FlUGwMGnizrr7+pZLw5OTI82tYpEecZeDoB0MN4GNY9es080PUXl8KQzekptMLcDXyoSVz30aqg0isUdWoY9aDR/qEd4zpaIxNeWAKuDXiRijyW1gxDa6bya1mokAiLmAYgpJsJkDggCOn6mIbertaLorzeOlvVSRYfuMr9FyuOscnt1q/gs6eRNpNb7lIrvrVYat6qDZ0fPvEu/fQhCC+1KMa8+iddd6z8IxrmxNVE8nueMq3Jb2HHWfE1Rd7Lyt0ggCGiEs8NJW+rwYloY+e7c+ACBAFOrpmgqszTCxJyNGogQXomELnMbZCK+fzRgZAR1AjPiQ88a9VuXGV+eY+K9C//vJaNL6oBCVwBkwf7POThqgJZgQvyeJfdIzXmJdq3PLDBx82LislMwi1BGg5GZyN81x8g2zl+B0Ucj2KPB9pExqYSeKy6Wzbiu60oUJADteoBdKaCSksuXy09jez1au/io9ZFOAMFQS3OeOX4Pxddd2JmraH+A7Al8msZZvpqqGcxhAOYzZL2IZ3S5N1b+rla4YMvSxhGJSKe7hfZ3tw8Jy248cI0zv1Ia/KOTtzjjyOYqSg== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM0PR03MB4882.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230022)(346002)(376002)(396003)(366004)(136003)(39840400004)(451199015)(66574015)(8676002)(71200400001)(316002)(478600001)(186003)(6916009)(54906003)(7696005)(83380400001)(4326008)(53546011)(41300700001)(64756008)(66446008)(91956017)(76116006)(66476007)(66946007)(9686003)(6506007)(8936002)(66556008)(26005)(966005)(107886003)(5660300002)(33656002)(86362001)(52536014)(38070700005)(122000001)(2906002)(38100700002)(55016003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-2?Q?pV9SGz+mzPcXvDV7f1bUSPJO9Q2BmEjWJij8smhbO+TWfzME2HPgwZtucE?= =?iso-8859-2?Q?Zi/CaT9VLKnzrrc02E8tISMRIoBNtLIZXpKkDBMDpKfHd0heneQC1E63UG?= =?iso-8859-2?Q?dLYMyC0rfUmQcm3+7HYXNQHh/2hj9oJtAwaXFjvEnIh76Pj0P3psfvodIE?= =?iso-8859-2?Q?kexomXmOhM2TQ6z5DUFj/snC0wddjDBNj2wD33cEvaJLL27Kbn/+XA6rKj?= =?iso-8859-2?Q?lJhsMQByQDr/Sx4erqhsr2gZ7QIqTRruziDmx/Woq0EIt7eZXnRItCUoTi?= =?iso-8859-2?Q?IRlkIIl9gK6oogsq5VIoUKhp4HE5DqsHq9Sp1vM5jyi3voZLTed+f3cMqp?= =?iso-8859-2?Q?hxFSysXcaok6hMiEy/V24JKL+e7RSRYaVrRz4cSvJS+565s+qQOMFSyRa+?= =?iso-8859-2?Q?kwF+ey3VKN1zlLhUkNE50LZB88o7T7hu4d7PvDVCHqcVtV2K9IUW7O+hUF?= =?iso-8859-2?Q?cehtL2uXz4XbJe/cf9QuUiK4Uv5YiGvINRWnHnjMAgx0vrBfxPQ0xG96vr?= =?iso-8859-2?Q?1g3yJAWO1sn75BEAbE1JlfbcBWEbdUDDeW7uiVjwTzX1qIPtLVjyjGld6q?= =?iso-8859-2?Q?0/h8d3BTaXcDggBjNrK8yM14Qza+u0jPKhd+RHqaS/TWiBbTjdi8mcCy49?= =?iso-8859-2?Q?w2dv28SB1evOdyucPrcb9rBp0r299dWztd5gxlCUQbQPISgxn9NgyW1xFw?= =?iso-8859-2?Q?ugKshMsGgwIJpeigWKm9DCizjIDJ8LCefg/pgnI+1zMDa7SMBq/q3E93OC?= =?iso-8859-2?Q?0nXMkaqEhPCr394ODBjJMQMvmG5cQRVLAjNKkivUFgyM6w9H3MaB7zlm7x?= =?iso-8859-2?Q?b2DPuLt0Yvdfh6yXQ6kLMsSto7i5pHEQpfg9/TpxvyNVn33rOF29XFeSFo?= =?iso-8859-2?Q?JhVFqSOOWVb9d2U+EJn3RFfi5KYsRqq101G2+hzY3aOSNHvn2LskVWQn1O?= =?iso-8859-2?Q?lOgK6MvPh+C2p2JrEFOg5Dg3yTmRSZ+bIGbJ8WmeVlbZRPaOt2izi4t6Li?= =?iso-8859-2?Q?Nk6CZlU81+Fo48/lt3o5DGjdhcw5LTsXZKjvAwGtiw+Fuo1EIsZUdDRUdj?= =?iso-8859-2?Q?7iJmQdn2Tc3dG4M9UbC7ylKc0V0rPv35bMuDt5lgbII0DuxA1K+aLBcYlJ?= =?iso-8859-2?Q?JXKSvI+0dqBoag++5JbpEcWIcbceRdy/5nwP/7P9uwQmxxO5HubrqBiN17?= =?iso-8859-2?Q?IvVIXSne62NC90V3zWU4NZwgypnjSMxceALzyDLqt/oYBrtsWCWtkge55Z?= =?iso-8859-2?Q?INqaGLI4ZQloS6CUX/SK5+Ex2C0jDKFfEGJ8ur/RwFNXHF5Q1AvVc/Z/J7?= =?iso-8859-2?Q?4Pzc7pojaRLHJ1Z8JxdRyI805CU1F7/hJtidSTweGUdT1Op1rkPny/mhRy?= =?iso-8859-2?Q?tEnPaurAdbFSWi5V4cyUhCGyjw3UcOIB/XCg32CchZKUvCcSAyExQwgtvG?= =?iso-8859-2?Q?u2rbHBU/IpI40m7gM8ePYyHndNuiPJjZUrJ7sDXxPDhQZxSKF2c1+T2IR5?= =?iso-8859-2?Q?RPRFG7Qz42p72AVpsDYxOoZl9r/RZOC/D86UbXJuExcdbCiA7ktB1wb7Y1?= =?iso-8859-2?Q?xHPt5px3rkQiUnmt9JReWGkFRKVo/jWA/fwg0GAhyoV3qJS7WWzrnWcnc1?= =?iso-8859-2?Q?pkdhNujN7akmzlEFZvjELnLmJ1yJ01HI/xVp7kwGZVCIMZrIWWUdFRUA?= =?iso-8859-2?Q?=3D=3D?= Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: syrmia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR03MB4882.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a4baf80a-0483-488f-09f4-08dab8e9c8e3 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Oct 2022 13:39:06.3247 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 19214a73-c1ab-4e19-8f59-14bdcb09a66e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: GGXd8mkBNSH8szAbERS867RjM8R080MX8+CI0qFEicfrYVBKE8eciWpOwMKVZbXecUzZ1ZlkRLdksI/IgBuAAv/DYzSyinaKQPjF8dV0Rfs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR03MB8164 X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,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: Hi Richard,=0A= =0A= > But something is wrong then - it shouldn't ever pick a candidate with=0A= > an addressing=0A= > mode that isn't supported?=0A= =0A= Test case I presented in [0] only has non-"BASE + OFFSET" candidates. Corre= ct me=0A= if I'm wrong, but the candidate selection algorithm doesn't take into accou= nt=0A= which addressing modes are supported by the target?=0A= =0A= > So you say that the cost of expressing=0A= > 'BASE + INDEX << SCALE + OFFSET' as 'BASE + OFFSET' is not computed=0A= > accurately?=0A= =0A= I just took it as an example, but yes.=0A= =0A= > The function tries to compensate for that, maybe you can point out=0A= > where it goes wrong?=0A= > That is, at the end it adjusts cost and complexity based on what it=0A= > scrapped before, maybe=0A= > that is just a bit incomplete?=0A= =0A= I think the cost.cost part is mostly okay, as the costs are just scaled =0A= (what was lesser/higher before f9f69dd is lesser/higher after f9f69dd).=0A= As far as the adjustments go, I don't think they are complete. =0A= On the other hand, as complexity is a valid part of address costs, and=0A= it can be used as a tie-breaker, I feel like it should serve a purpose, =0A= even for targets like Mips which are limited when it comes to =0A= addressing modes, rather than being equal to 0.=0A= =0A= I guess an alternative would be to fully cover cost.cost adjustments, and= =0A= leave the complexities to be 0 for non-supported addressing modes.=0A= Currently, they are implemented as follows:=0A= =0A= if (simple_inv)=0A= simple_inv =3D (aff_inv =3D=3D NULL=0A= || aff_combination_const_p (aff_inv)=0A= || aff_combination_singleton_var_p (aff_inv));=0A= if (!aff_combination_zero_p (aff_inv))=0A= comp_inv =3D aff_combination_to_tree (aff_inv);=0A= if (comp_inv !=3D NULL_TREE)=0A= cost =3D force_var_cost (data, comp_inv, inv_vars);=0A= if (ratio !=3D 1 && parts.step =3D=3D NULL_TREE)=0A= var_cost +=3D mult_by_coeff_cost (ratio, addr_mode, speed);=0A= if (comp_inv !=3D NULL_TREE && parts.index =3D=3D NULL_TREE)=0A= var_cost +=3D add_cost (speed, addr_mode);=0A= =0A= > Note the original author of this is not available so it would help=0A= > (maybe also yourself) to=0A= > walk through the function with a specific candidate / use where you=0A= > think the complexity=0A= > (or cost) is wrong?=0A= =0A= I'd like to refer to [0] where candidate costs didn't get adjusted to =0A= cover the lack of complexity calculation.=0A= =0A= Would love to hear your thoughts.=0A= =0A= [0] https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604304.html=0A= =0A= Regards,=0A= Dimitrije=0A= =0A= From: Richard Biener =0A= Sent: Friday, October 28, 2022 9:00 AM=0A= To: Dimitrije Milosevic =0A= Cc: Jeff Law ; gcc-patches@gcc.gnu.org ; Djordje Todorovic =0A= Subject: Re: [PATCH 1/2] ivopts: Revert computation of address cost complex= ity. =0A= =A0=0A= On Fri, Oct 28, 2022 at 8:43 AM Dimitrije Milosevic=0A= wrote:=0A= >=0A= > Hi Jeff,=0A= >=0A= > > THe part I don't understand is, if you only have BASE+OFF, why does=0A= > > preventing the calculation of more complex addressing modes matter?=A0 = ie,=0A= > > what's the point of computing the cost of something like base + off += =0A= > > scaled index when the target can't utilize it?=0A= >=0A= > Well, the complexities of all addressing modes other than BASE + OFFSET a= re=0A= > equal to 0. For targets like Mips, which only has BASE + OFFSET, it would= still=0A= > be more complex to use a candidate with BASE + INDEX << SCALE + OFFSET=0A= > than a candidate with BASE + INDEX, for example, as it has to compensate= =0A= > the lack of other addressing modes somehow. If complexities for both of= =0A= > those are equal to 0, in cases where complexities decide which candidate = is=0A= > to be chosen, a more complex candidate may be picked.=0A= =0A= But something is wrong then - it shouldn't ever pick a candidate with=0A= an addressing=0A= mode that isn't supported?=A0 So you say that the cost of expressing=0A= 'BASE + INDEX << SCALE + OFFSET' as 'BASE + OFFSET' is not computed=0A= accurately?=0A= =0A= The function tries to compensate for that, maybe you can point out=0A= where it goes wrong?=0A= That is, at the end it adjusts cost and complexity based on what it=0A= scrapped before, maybe=0A= that is just a bit incomplete?=0A= =0A= Note the original author of this is not available so it would help=0A= (maybe also yourself) to=0A= walk through the function with a specific candidate / use where you=0A= think the complexity=0A= (or cost) is wrong?=0A= =0A= =0A= > Regards,=0A= > Dimitrije=0A= >=0A= >=0A= > From: Jeff Law =0A= > Sent: Friday, October 28, 2022 1:02 AM=0A= > To: Dimitrije Milosevic ; gcc-patches@gcc= .gnu.org =0A= > Cc: Djordje Todorovic =0A= > Subject: Re: [PATCH 1/2] ivopts: Revert computation of address cost compl= exity.=0A= >=0A= >=0A= > On 10/21/22 07:52, Dimitrije Milosevic wrote:=0A= > > From: Dimitrije Milo=B9evi=E6 =0A= > >=0A= > > This patch reverts the computation of address cost complexity=0A= > > to the legacy one. After f9f69dd, complexity is calculated=0A= > > using the valid_mem_ref_p target hook. Architectures like=0A= > > Mips only allow BASE + OFFSET addressing modes, which in turn=0A= > > prevents the calculation of complexity for other addressing=0A= > > modes, resulting in non-optimal candidate selection.=0A= > >=0A= > > gcc/ChangeLog:=0A= > >=0A= > >=A0=A0=A0=A0=A0=A0=A0 * tree-ssa-address.cc (multiplier_allowed_in_addre= ss_p): Change=0A= > >=A0=A0=A0=A0=A0=A0=A0 to non-static.=0A= > >=A0=A0=A0=A0=A0=A0=A0 * tree-ssa-address.h (multiplier_allowed_in_addres= s_p): Declare.=0A= > >=A0=A0=A0=A0=A0=A0=A0 * tree-ssa-loop-ivopts.cc (compute_symbol_and_var_= present): Reintroduce.=0A= > >=A0=A0=A0=A0=A0=A0=A0 (compute_min_and_max_offset): Likewise.=0A= > >=A0=A0=A0=A0=A0=A0=A0 (get_address_cost): Revert=0A= > >=A0=A0=A0=A0=A0=A0=A0 complexity calculation.=0A= >=0A= > THe part I don't understand is, if you only have BASE+OFF, why does=0A= > preventing the calculation of more complex addressing modes matter?=A0 ie= ,=0A= > what's the point of computing the cost of something like base + off +=0A= > scaled index when the target can't utilize it?=0A= >=0A= >=0A= > jeff=0A= >=