From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on2052.outbound.protection.outlook.com [40.107.13.52]) by sourceware.org (Postfix) with ESMTPS id 293B13858407 for ; Tue, 9 Jan 2024 13:58:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 293B13858407 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 293B13858407 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=40.107.13.52 ARC-Seal: i=3; a=rsa-sha256; d=sourceware.org; s=key; t=1704808733; cv=pass; b=oxEH4+wJcvU63/bWocOi7BZTFxHpDEoMZacdrLZtxaCZhQ4t9Pn5d0VV8rsEGulCIm9RCtESmbal0euCn1gwlHcbMjguC3SdK6cdr93BJF4wx3lShxAA26nzDFK+4LF+cDsqQeJMKrzpQKt29h50YJDdx/wYq1bE7jmKsxAzyAI= ARC-Message-Signature: i=3; a=rsa-sha256; d=sourceware.org; s=key; t=1704808733; c=relaxed/simple; bh=cH3iblDLtNpNpXyCSWBBKNd78FMmqp1tBSqa6IIu2sg=; h=DKIM-Signature:DKIM-Signature:From:To:Subject:Date:Message-ID: MIME-Version; b=CXEE9r3zMP7JkV6W33EUAvdTvbV1lWK/o+mZt717nPmDW2Ks9+6ghE45eWbo1Le5RdMpZTV2T0RCy51E2Oenw6Vcbck401V706K1NLYAPGj8lPuwjgBgFbnkeAv/M7RiiVe3lPdNdVMgoh7E5QEZOf+Wk2eGMDMoRKRKK8zue/Y= ARC-Authentication-Results: i=3; server2.sourceware.org ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=V5r9hu8lMe/FRKAUcTj2Qw79KlvUEzoCnlH3JHFs9hK2hgOW9KuafMEbxLP8sP8ODf8ubgeQUpDiRfoo8QTX9DjOFqhrrEUWMbpmWifSERG52rOjHE4ZDvOj67ETW2FwtvaqhWqGQpNW+2jvQo0D4wKlza1PP+34coTJ5zlhPZKQ0a5SHwuj3StotnJ/KwyXEGtUAdL7KpLSsGc3WVgfZnr3V05zgQLVxEqdlDCp4d91f/TLK6OPtKQfQebEEXLAtRzxZa1vQy/i2KkN0ermi4CYUaxmnZm9X9iPMkV1oFy7u9eAheco1fH8fhn3LrlvJhWenSeNLb62r4BovtILiw== ARC-Message-Signature: i=2; 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=QL+0a/8zYWvs+SeHgBICig7PQrCy5yX+qbSsvAcka+s=; b=lSaQr7obcqQK9wiTmh3hFiRQqgveMz+kQFk/If/+IlgCzWvAf0Nv4EHsyQq67QStqTEHCC4h+8qS/Mxon4eGWP3lhXipX36NgUxZiGOoWCWBaahy2QmDIxoeGFo4tNbmfTK94qWGW6IKYuWajdpIMcAs/GwqlDJBVZg09h7xQUQI+G6KdrKRfSQFa0KWn0b5cvjD0ODtq/gLV4vvFobe8lD0btuKj90nhIwVzErux33X2Ev18bNx2QMj6PDO0aGV/1eLk43LbWg4L3EDPsNnBg/IvolEbFnrX9pV28hFQmvmFfL4PWHKHu+IDvtQdSHA/fkxHwjg20Ol2L8lL9ZdHA== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=gcc.gnu.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QL+0a/8zYWvs+SeHgBICig7PQrCy5yX+qbSsvAcka+s=; b=XaM5kgdG6ON2ltplba8Rk6/GnRCdvf0BlHL6V/BO5IGyN6+OVPgCslg3q1rqG5tXo7qNNOlZpWFP5g58NKiZQ/CKrxybRmYi9WANmFIZWFb3NKEp6oOIbHShj3FjAi13ZVdVs7Z0EqrHDpYt8v+CjCDQlcHI/Q8+7MiLu0ihJOs= Received: from DUZPR01CA0038.eurprd01.prod.exchangelabs.com (2603:10a6:10:468::12) by DU0PR08MB9822.eurprd08.prod.outlook.com (2603:10a6:10:445::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7159.21; Tue, 9 Jan 2024 13:58:46 +0000 Received: from DU6PEPF0000B61D.eurprd02.prod.outlook.com (2603:10a6:10:468:cafe::a7) by DUZPR01CA0038.outlook.office365.com (2603:10a6:10:468::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7159.23 via Frontend Transport; Tue, 9 Jan 2024 13:58:46 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; pr=C Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DU6PEPF0000B61D.mail.protection.outlook.com (10.167.8.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7181.14 via Frontend Transport; Tue, 9 Jan 2024 13:58:46 +0000 Received: ("Tessian outbound 52fd419df13e:v239"); Tue, 09 Jan 2024 13:58:46 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 7b8da3e3527395ed X-CR-MTA-TID: 64aa7808 Received: from 369a87240229.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 45AE9696-6AF1-4CB0-857B-AFE9CC1CF1CF.1; Tue, 09 Jan 2024 13:58:39 +0000 Received: from EUR03-AM7-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 369a87240229.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 09 Jan 2024 13:58:39 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=g48mFxyRWHGPatDxcLVPdtVrY6+0QcbcGFkcJ3l6swnzq81JdH0yDbUumnFvk5xX31flCdk0I4YgWtNBY5cJGBXQvR+6BqgYOfkLH7TevkQ7SyGo4vCwYzIKtrYwkHA5CDxtMkTU64r75UqyH8UReP5ReWA7xIztsNjrJqGXzyPGF+s+WsDhScOWVwN/9UZn6sKSNCL/5Wj0XBnK0qBaqFlPc/jzcOR9fDBSbOC1bfdz0RvP8Jn7seXojq3qf6MGhqjSPQ0rwx/z/9m9ku08fMIFoF1xP0CqkizY6/6UfzlmwINZbjA53Bzub9xT50XD8uzRYX4MrAt90xHlbwzX+Q== 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=QL+0a/8zYWvs+SeHgBICig7PQrCy5yX+qbSsvAcka+s=; b=fYD9Vf6azOBwgKAwsPeRt/bH/nbYQ9NP7gH5yqg5FpsbLnm7pOQ9jCLYMflywgCsVg0xDZEAQK2ACSBuGM98CMKUubR4OEWCpl+eJprRSW/k08PIOB6hAjKKYcTst5CTUcY06I/qWGOeSwtzaMNCQWYX0fsRk81UYN+6BaEAkq1zFmAeuOeyrbDshBMXzw+NIEVirgnfO5AEEhIGWe8FvG9VxBmXDK/AnScQPDUOn3D1owvNfdFuVUM0hTzSwnYv3gI7+qClbiUhdxNLN1C89bOGrsITvoNYsRCZMt90cI6FpwPvrakD/yEnAdcYobJtL1iJ+8vRNRPtONLBVm0IRQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QL+0a/8zYWvs+SeHgBICig7PQrCy5yX+qbSsvAcka+s=; b=XaM5kgdG6ON2ltplba8Rk6/GnRCdvf0BlHL6V/BO5IGyN6+OVPgCslg3q1rqG5tXo7qNNOlZpWFP5g58NKiZQ/CKrxybRmYi9WANmFIZWFb3NKEp6oOIbHShj3FjAi13ZVdVs7Z0EqrHDpYt8v+CjCDQlcHI/Q8+7MiLu0ihJOs= Received: from VI1PR08MB5325.eurprd08.prod.outlook.com (2603:10a6:803:13e::17) by VI0PR08MB10581.eurprd08.prod.outlook.com (2603:10a6:800:20e::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7159.21; Tue, 9 Jan 2024 13:58:34 +0000 Received: from VI1PR08MB5325.eurprd08.prod.outlook.com ([fe80::9679:2ab0:99c6:54a3]) by VI1PR08MB5325.eurprd08.prod.outlook.com ([fe80::9679:2ab0:99c6:54a3%6]) with mapi id 15.20.7159.020; Tue, 9 Jan 2024 13:58:34 +0000 From: Tamar Christina To: Richard Biener CC: "gcc-patches@gcc.gnu.org" , nd , "jlaw@ventanamicro.com" Subject: RE: [PATCH]middle-end: Fix dominators updates when peeling with multiple exits [PR113144] Thread-Topic: [PATCH]middle-end: Fix dominators updates when peeling with multiple exits [PR113144] Thread-Index: AQHaOmV5Le9fU51rpEKy6ygkeBVv0rDP5QwAgAGJDUCAAAr9gIAADnoQgAAEy4CAAASRAIAAAdWQ Date: Tue, 9 Jan 2024 13:58:33 +0000 Message-ID: References: <8pn44s40-pqs9-s99r-6qs4-1p9432692p7q@fhfr.qr> <4p54n752-rs8o-o37o-7q5r-npp5onp9sqrr@fhfr.qr> In-Reply-To: <4p54n752-rs8o-o37o-7q5r-npp5onp9sqrr@fhfr.qr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: VI1PR08MB5325:EE_|VI0PR08MB10581:EE_|DU6PEPF0000B61D:EE_|DU0PR08MB9822:EE_ X-MS-Office365-Filtering-Correlation-Id: f2f6b0cd-d3c1-4ef0-659a-08dc111b192e x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: aalDA8Y4a5OiwollSjXkaBIGegI2qQZgNmaE2LfZIxBUDuQyTNIluIXcW3WZ0BgJDjhjYboUEGPZ2fkvSOo6tPL5rSdgYVZ9JEuEgAt5sBgYPnrO2moZbQNEl1pFQebx8jM3yKsRH8rH2KuqC8W+jcvO2YVFIavmn4vhwta/nRCm05dzQ3KTdrN30K/EPwgS1y5UQ18Fm6qj/9VWddlY9y/nJMnvFnOicvbqR6RWi+kMRQVX2Of/DrqKN96VOaumNDNC9hG2AeO9/ZPqP05dS0ZCapoPC3v0gw2DyKTIHqNJDfocvk3arA/3mOfADiCyiTSkU6e4fvY4wDrOyeLuGQu1bPOz1Sb48+10UXSsCIi38aNzK8eOuRFk8/cJRFIdoFAz+vITKCXhZQpl5EThPLKDmnJlMSFsuWyEBs80XQ+Q55PVBjy9s31gKdeUeUIAV+sMyY4BBR1jRsumGK2Jn3uaJrQpIeWC7KSaXfZ7D6e0x1rHeeT7mLh+Rohi9aUheFd5YDkZCk81VlqbVPC3tWXaJboQvBaZV+vu8CobyFyuDouUJYCOghrJetXURpUcmFPu3UUtXL3gtBFDt4LmyTdzS1LRlvNMoK2mykBVFTnAWfq7OciLqICK2bSZdJQOPP0o6vh1aTxdzg32Pf/F9Q== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VI1PR08MB5325.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(136003)(376002)(396003)(366004)(346002)(39860400002)(230922051799003)(451199024)(64100799003)(186009)(1800799012)(53546011)(122000001)(38070700009)(38100700002)(4326008)(2906002)(30864003)(5660300002)(15650500001)(316002)(478600001)(966005)(7696005)(9686003)(33656002)(71200400001)(83380400001)(6506007)(66476007)(54906003)(26005)(52536014)(66946007)(66446008)(64756008)(6916009)(76116006)(66556008)(8936002)(86362001)(41300700001)(8676002)(55016003)(84970400001);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR08MB10581 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DU6PEPF0000B61D.eurprd02.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: ce99026a-46e4-42f8-a87a-08dc111b11c7 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Q3sGShChbfF+Mhk36CAz5E0ieUOzmPPMi5doT0m1bwcVbagF0sRHPFZJz2hwkkfU/RLLBKmFFd6tYgR7CDdLelmfTGpPV1TPN4h5BUqZGjaCXTe9LVWxft4ejk6DGqqVYdr5eQBYzorNaEC1a79u8PKAafqnRvmMuJ6dXHWl+2+dfM0xZcXrITj9ee0YFAVM/yR+hNtVgWQJagOPicr83ViwulHjNpOQVCNYpbPmDaj6chm0ICDShOFplDSPdE5METFc2tCsg9nCk/066BHwLo6Uj0MmnFdv7H5dM/rSLQ8fVC0yS5XL8ZM/uvm5Lt1rcLiJL06Owq685RwS8mVdcKWJM0wMMX6mfnMHFL/tuw+IT6lHIzhpenQ/2PjV0Z7bQu2UFtHs7qG6HkCpgkv2ZVdfvPORjLgK8eqxfhltmX5RGZLAg/JxBJLSyPqVxuVqR93JEQ8y+YljHyGHqgZkXiU4+4+4p4jZr18jZL67aSUB10fvha8UQd5Ko2Eqc+J4b2wYniKu7GOOUPKU4mN2zAZFlrQHEzCeOPnzM/D8ATMtlv5+s6irRG/mipVtrNyqTwLUwIDYcyJaPGNA3JKVDf+xTasabNoke2IueX/KHjC5tbH9iYiEFXmlGuI1Yz/oJ6E1cZe1Cv90lPfJ0weeMDVZIAkBPRYzV1oLZn5KHAtf8QfuJbuW0RdMU3xB4Wrk7n0rDaxxOPWKnyFDfVvDv4WsLkRqJOekDc1qjE2vSf3JAUrYte1Gs/+d86h3s0vK9HXBfeRKFMfzXo0p9CBYsQ== X-Forefront-Antispam-Report: CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com;CAT:NONE;SFS:(13230031)(4636009)(136003)(39860400002)(346002)(376002)(396003)(230922051799003)(186009)(64100799003)(451199024)(1800799012)(82310400011)(36840700001)(40470700004)(46966006)(40460700003)(40480700001)(55016003)(84970400001)(26005)(53546011)(9686003)(336012)(478600001)(6506007)(7696005)(966005)(82740400003)(36860700001)(33656002)(86362001)(81166007)(356005)(15650500001)(2906002)(41300700001)(107886003)(83380400001)(5660300002)(70586007)(30864003)(54906003)(70206006)(316002)(8936002)(4326008)(52536014)(8676002)(6862004)(47076005);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jan 2024 13:58:46.4028 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f2f6b0cd-d3c1-4ef0-659a-08dc111b192e X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DU6PEPF0000B61D.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB9822 X-Spam-Status: No, score=-12.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,FORGED_SPF_HELO,GIT_PATCH_0,KAM_DMARC_NONE,KAM_SHORT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE,UNPARSEABLE_RELAY 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: > -----Original Message----- > From: Richard Biener > Sent: Tuesday, January 9, 2024 1:51 PM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; jlaw@ventanamicro.com > Subject: RE: [PATCH]middle-end: Fix dominators updates when peeling with > multiple exits [PR113144] >=20 > On Tue, 9 Jan 2024, Richard Biener wrote: >=20 > > On Tue, 9 Jan 2024, Tamar Christina wrote: > > > > > > > > > > > > -----Original Message----- > > > > From: Richard Biener > > > > Sent: Tuesday, January 9, 2024 12:26 PM > > > > To: Tamar Christina > > > > Cc: gcc-patches@gcc.gnu.org; nd ; jlaw@ventanamicro.com > > > > Subject: RE: [PATCH]middle-end: Fix dominators updates when peeling= with > > > > multiple exits [PR113144] > > > > > > > > On Tue, 9 Jan 2024, Tamar Christina wrote: > > > > > > > > > > This makes it quadratic in the number of vectorized early exit = loops > > > > > > in a function. The vectorizer CFG manipulation operates in a l= ocal > > > > > > enough bubble that programmatic updating of dominators should b= e > > > > > > possible (after all we manage to produce correct SSA form!), th= e > > > > > > proposed change gets us too far off to a point where re-computa= ting > > > > > > dominance info is likely cheaper (but no, we shouldn't do this = either). > > > > > > > > > > > > Can you instead give manual updating a try again? I think > > > > > > versioning should produce up-to-date dominator info, it's only > > > > > > when you redirect branches during peeling that you'd need > > > > > > adjustments - but IIRC we're never introducing new merges? > > > > > > > > > > > > IIRC we can't wipe dominators during transform since we query t= hem > > > > > > during code generation. We possibly could code generate all > > > > > > CFG manipulations of all vectorized loops, recompute all domina= tors > > > > > > and then do code generation of all vectorized loops. > > > > > > > > > > > > But then we're doing a loop transform and the exits will ultima= tively > > > > > > end up in the same place, so the CFG and dominator update is bo= und to > > > > > > where the original exits went to. > > > > > > > > > > Yeah that's a fair point, the issue is specifically with at_exit.= So how about: > > > > > > > > > > When we peel at_exit we are moving the new loop at the exit of th= e > previous > > > > > loop. This means that the blocks outside the loop dat the previo= us loop > used to > > > > > dominate are no longer being dominated by it. > > > > > > > > Hmm, indeed. Note this does make the dominator update O(function-s= ize) > > > > and when vectorizing multiple loops in a function this becomes > > > > quadratic. That's quite unfortunate so I wonder if we can delay th= e > > > > update to the parts we do not need up-to-date dominators during > > > > vectorization (of course it gets fragile with having only partly > > > > correct dominators). > > > > > > Fair, I created https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D113290= and will > > > tackle it when I add SLP support in GCC 15. > > > > > > I think the problem is, and the reason we do early dominator correcti= on and > > > validation is because the same function is used by loop distribution. > > > > > > But you're right that during vectorization we perform dominators upda= te twice > > > now. > > > > We're performing it at least once per multi-exit loop that is vectorize= d, > > covering all downstream blocks. >=20 > That is, consider sth like >=20 > int a[77]; >=20 > int bar (); > void foo () > { > int val; > #define LOOP \ > val =3D bar (); \ > for (int i =3D 0; i < 77; ++i) \ > { \ > if (a[i] =3D=3D val) \ > break; \ > a[i]++; \ > } > #define LOOP10 LOOP LOOP LOOP LOOP LOOP LOOP LOOP LOOP LOOP LOOP > #define LOOP100 LOOP10 LOOP10 LOOP10 LOOP10 LOOP10 LOOP10 LOOP10 > LOOP10 > LOOP10 LOOP10 > #define LOOP1000 LOOP100 LOOP100 LOOP100 LOOP100 LOOP100 LOOP100 > LOOP100 > LOOP100 LOOP100 LOOP100 > LOOP1000 > } >=20 > where on x86_64 with -O3 -msse4.1 -fno-gcse -fno-gcse-after-reload we're > currently "fine" (calling iterate_fix_dominators 2000 times). But > with geting all dominated blocks you should get every block to exit > "fixed" and maybe get dominance compute to show up in the profile. >=20 Yeah, that makes sense. If we can move loop distribution to a different me= thod, then we can just perform dominators update only once for all loops at the e= nd of vectorization right? Thanks, Tamar > Richard. >=20 >=20 > > > So Maybe we should have a parameter to indicate whether dominators sh= ould > > > be updated? > > > > I think we should possibly try making loop distribution use another > > mechanism for its copying ... there's duplicate_loop_body_to_header_edg= e > > that's also used by loop_version, the core parts doing the new > > loop creation could be split out and the detail how the final CFG > > is set up be retained in two workers. > > > > Richard. > > > > > Thanks, > > > Tamar > > > > > > > > > > > > The new dominators however are hard to predict since if the loop = has > multiple > > > > > exits and all the exits are an "early" one then we always execute= the scalar > > > > > loop. In this case the scalar loop can completely dominate the n= ew loop. > > > > > > > > > > If we later have skip_vector then there's an additional skip edge= added that > > > > > might change the dominators. > > > > > > > > > > The previous patch would force an update of all blocks reachable = from the > new > > > > > exits. This one updates *only* blocks that we know the scalar ex= its > dominated. > > > > > > > > > > For the examples this reduces the blocks to update from 18 to 3. > > > > > > > > > > Bootstrapped Regtested on aarch64-none-linux-gnu, x86_64-pc-linux= -gnu > > > > > and no issues normally and with --enable-checking=3Drelease --ena= ble-lto > > > > > --with-build-config=3Dbootstrap-O3 --enable-checking=3Dyes,rtl,ex= tra. > > > > > > > > > > Ok for master? > > > > > > > > See below. > > > > > > > > > Thanks, > > > > > Tamar > > > > > > > > > > gcc/ChangeLog: > > > > > > > > > > PR tree-optimization/113144 > > > > > PR tree-optimization/113145 > > > > > * tree-vect-loop-manip.cc (slpeel_tree_duplicate_loop_to_edge_cf= g): > > > > > Update all BB that the original exits dominated. > > > > > > > > > > gcc/testsuite/ChangeLog: > > > > > > > > > > PR tree-optimization/113144 > > > > > PR tree-optimization/113145 > > > > > * gcc.dg/vect/vect-early-break_94-pr113144.c: New test. > > > > > > > > > > --- inline copy of patch --- > > > > > > > > > > diff --git a/gcc/testsuite/gcc.dg/vect/vect-early-break_94-pr1131= 44.c > > > > b/gcc/testsuite/gcc.dg/vect/vect-early-break_94-pr113144.c > > > > > new file mode 100644 > > > > > index > > > > > 0000000000000000000000000000000000000000..903fe7be6621e81db6f294 > > > > 41e4309fa213d027c5 > > > > > --- /dev/null > > > > > +++ b/gcc/testsuite/gcc.dg/vect/vect-early-break_94-pr113144.c > > > > > @@ -0,0 +1,41 @@ > > > > > +/* { dg-do compile } */ > > > > > +/* { dg-add-options vect_early_break } */ > > > > > +/* { dg-require-effective-target vect_early_break } */ > > > > > +/* { dg-require-effective-target vect_int } */ > > > > > + > > > > > +/* { dg-final { scan-tree-dump "LOOP VECTORIZED" "vect" } } */ > > > > > + > > > > > +long tar_atol256_max, tar_atol256_size, tar_atosl_min; > > > > > +char tar_atol256_s; > > > > > +void __errno_location(); > > > > > + > > > > > + > > > > > +inline static long tar_atol256(long min) { > > > > > + char c; > > > > > + int sign; > > > > > + c =3D tar_atol256_s; > > > > > + sign =3D c; > > > > > + while (tar_atol256_size) { > > > > > + if (c !=3D sign) > > > > > + return sign ? min : tar_atol256_max; > > > > > + c =3D tar_atol256_size--; > > > > > + } > > > > > + if ((c & 128) !=3D (sign & 128)) > > > > > + return sign ? min : tar_atol256_max; > > > > > + return 0; > > > > > +} > > > > > + > > > > > +inline static long tar_atol(long min) { > > > > > + return tar_atol256(min); > > > > > +} > > > > > + > > > > > +long tar_atosl() { > > > > > + long n =3D tar_atol(-1); > > > > > + if (tar_atosl_min) { > > > > > + __errno_location(); > > > > > + return 0; > > > > > + } > > > > > + if (n > 0) > > > > > + return 0; > > > > > + return n; > > > > > +} > > > > > diff --git a/gcc/tree-vect-loop-manip.cc b/gcc/tree-vect-loop-man= ip.cc > > > > > index > > > > > 76d4979c0b3b374dcaacf6825a95a8714114a63b..9bacaa182a3919cae1cb99dfc > > > > 5ae4923e1f93376 100644 > > > > > --- a/gcc/tree-vect-loop-manip.cc > > > > > +++ b/gcc/tree-vect-loop-manip.cc > > > > > @@ -1719,8 +1719,6 @@ slpeel_tree_duplicate_loop_to_edge_cfg (cla= ss > loop > > > > *loop, edge loop_exit, > > > > > /* Now link the alternative exits. */ > > > > > if (multiple_exits_p) > > > > > { > > > > > - set_immediate_dominator (CDI_DOMINATORS, new_preheader, > > > > > - main_loop_exit_block); > > > > > for (auto gsi_from =3D gsi_start_phis (loop->header), > > > > > gsi_to =3D gsi_start_phis (new_preheader); > > > > > !gsi_end_p (gsi_from) && !gsi_end_p (gsi_to); > > > > > @@ -1776,7 +1774,14 @@ slpeel_tree_duplicate_loop_to_edge_cfg (cl= ass > loop > > > > *loop, edge loop_exit, > > > > > { > > > > > update_loop =3D new_loop; > > > > > for (edge e : get_loop_exit_edges (loop)) > > > > > - doms.safe_push (e->dest); > > > > > + { > > > > > + /* Basic blocks that the old loop dominated are now domin= ated > by > > > > > + the new loop and so we have to update those. */ > > > > > + for (auto bb : get_all_dominated_blocks (CDI_DOMINATORS, = e- > >src)) > > > > > + if (!flow_bb_inside_loop_p (loop, bb)) > > > > > + doms.safe_push (bb); > > > > > + doms.safe_push (e->dest); > > > > > + } > > > > > > > > I think you'll get duplicate blocks that way. Maybe simplify this > > > > all by instead doing > > > > > > > > auto doms =3D get_all_dominated_blocks (CDI_DOMINATORS, l= oop- > >header); > > > > for (unsigned i =3D 0; i < doms.length (); ++i) > > > > if (flow_bb_inside_loop_p (loop, doms[i])) > > > > doms.unordered_remove (i); > > > > > > > > ? > > > > > > > > OK with that change, but really we should see to avoid this > > > > quadraticness :/ It's probably not too bad right now given we have > > > > quite some restrictions on vectorizing loops with multiple exits, > > > > but I suggest you try an artificial testcase with the "same" > > > > loop repeated N times to see whether dominance compute creeps up > > > > in the profile. > > > > > > > > Richard. > > > > > > > >=20 > -- > Richard Biener > SUSE Software Solutions Germany GmbH, > Frankenstrasse 146, 90461 Nuernberg, Germany; > GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg= )