From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 72941 invoked by alias); 5 Nov 2019 14:09:33 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 72932 invoked by uid 89); 5 Nov 2019 14:09:33 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=H*i:sk:CAFiYyc X-HELO: EUR01-HE1-obe.outbound.protection.outlook.com Received: from mail-eopbgr130042.outbound.protection.outlook.com (HELO EUR01-HE1-obe.outbound.protection.outlook.com) (40.107.13.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 05 Nov 2019 14:09:26 +0000 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=aPSkTOa8MTZqIYTCm0sq7nWTBLo/aeJFDkOxwvETd+0=; b=w8Xgd6YQC50SNgWQ4bXCafQBsitbtnGsL6ZTuA4a9Yoml1eku10oVFxQDLOhHns69C/EsA4qWrtyZ8oeKAkfOi2x9I+4oQ+2gfAKl/T/DxjZ23Lp0W91y4vXuVOPglP/kpi49xhcqRXoEn3aQDduzXO1vh4ZxZr9RcLuTY3LH1Y= Received: from DB6PR0801CA0049.eurprd08.prod.outlook.com (2603:10a6:4:2b::17) by AM6PR08MB2981.eurprd08.prod.outlook.com (2603:10a6:209:44::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2408.24; Tue, 5 Nov 2019 14:09:20 +0000 Received: from AM5EUR03FT028.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e08::208) by DB6PR0801CA0049.outlook.office365.com (2603:10a6:4:2b::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.20 via Frontend Transport; Tue, 5 Nov 2019 14:09:20 +0000 Authentication-Results: spf=fail (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; gcc.gnu.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;gcc.gnu.org; dmarc=none action=none header.from=arm.com; Received-SPF: Fail (protection.outlook.com: domain of arm.com does not designate 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT028.mail.protection.outlook.com (10.152.16.118) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.20 via Frontend Transport; Tue, 5 Nov 2019 14:09:19 +0000 Received: ("Tessian outbound 851a1162fca7:v33"); Tue, 05 Nov 2019 14:09:19 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 31d3c60152613839 X-CR-MTA-TID: 64aa7808 Received: from 459245ecc3b2.1 (cr-mta-lb-1.cr-mta-net [104.47.8.54]) by 64aa7808-outbound-1.mta.getcheckrecipient.com id 1444244B-A434-4506-A512-6F54A31DC780.1; Tue, 05 Nov 2019 14:09:13 +0000 Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03lp2054.outbound.protection.outlook.com [104.47.8.54]) by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 459245ecc3b2.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 05 Nov 2019 14:09:13 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CmCjJ+Y9MH2FHyr9lJlysK1ek3/W8vG6WmI6q7ZYGybubVXD0k/sCTQ7xtmaXvxQjxeb1kto++g8Gw6Zvtro5I0ZNhdF38/lsFTBKByy4aH1n3MhsqCCtP8+iFJ2AxWdVm5WlmMTti7IJQJmHt2JmwzZOTBHRG2NSa92voe9DJCHvRzul+S5H6rG83kl4oO79oH/SNb/NywCtti9pD0wQthcjz9rwOezZL5QS3Thc3kjXIT60QuSWWZEv8hP3zyAiyNn3nkaDp+nLZo/gvS5HJKJDC/jvKgkqvWAaWctkBwcYNI1EHLJgRs9MDKcfrkDHsJpknCRUk9PxcHHKx/c9A== 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-SenderADCheck; bh=aPSkTOa8MTZqIYTCm0sq7nWTBLo/aeJFDkOxwvETd+0=; b=eSPgzGHfLs6q9S4YoFKhQ5VfaKD8VpQ7DIKu+u7M2ojDGNQ7UyRTetAS7TwPDauvmGSTjdrgYY/lioAB34VedAZpwjzRKN7x56R5ifwXUyiXPDR1iLe2JbNVyfDkejPW3naGFTL0V+M9BXb+DFnxu6UKlpHgoA0cQ5P01RKwAbSMztoIPKnc67YKkrR5pB2XdlByCekY9RzpZaYT4IUSZj+mptqMUedp/3sf+IxPc71Hiauuspr2UfaBrTbOyQzvorZsyQIpstP//BJjhoLRLPyth/39ku2Q4jDg5+VMftbTjPgmyj9hjNIm4EibIiMfs5v6GI5sDcRou9Ggs5yc7Q== 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=aPSkTOa8MTZqIYTCm0sq7nWTBLo/aeJFDkOxwvETd+0=; b=w8Xgd6YQC50SNgWQ4bXCafQBsitbtnGsL6ZTuA4a9Yoml1eku10oVFxQDLOhHns69C/EsA4qWrtyZ8oeKAkfOi2x9I+4oQ+2gfAKl/T/DxjZ23Lp0W91y4vXuVOPglP/kpi49xhcqRXoEn3aQDduzXO1vh4ZxZr9RcLuTY3LH1Y= Received: from AM0PR08MB3140.eurprd08.prod.outlook.com (52.134.95.145) by AM0PR08MB3075.eurprd08.prod.outlook.com (52.134.92.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2408.24; Tue, 5 Nov 2019 14:09:12 +0000 Received: from AM0PR08MB3140.eurprd08.prod.outlook.com ([fe80::9ded:1181:9d29:5d68]) by AM0PR08MB3140.eurprd08.prod.outlook.com ([fe80::9ded:1181:9d29:5d68%3]) with mapi id 15.20.2408.024; Tue, 5 Nov 2019 14:09:12 +0000 From: Richard Sandiford To: Richard Biener CC: GCC Patches Subject: Re: [16/n] Apply maximum nunits for BB SLP Date: Tue, 05 Nov 2019 14:09:00 -0000 Message-ID: References: In-Reply-To: (Richard Biener's message of "Tue, 5 Nov 2019 14:21:49 +0100") user-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) mail-followup-to: Richard Biener ,GCC Patches , richard.sandiford@arm.com Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Richard.Sandiford@arm.com; x-checkrecipientrouted: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM;SFS:(10009020)(4636009)(376002)(39860400002)(396003)(366004)(346002)(136003)(199004)(189003)(6116002)(6512007)(11346002)(446003)(2616005)(6486002)(3846002)(6246003)(66946007)(102836004)(14444005)(71190400001)(305945005)(71200400001)(26005)(5024004)(6916009)(66066001)(186003)(256004)(229853002)(476003)(486006)(44832011)(6436002)(52116002)(4326008)(5660300002)(66476007)(7736002)(316002)(86362001)(8676002)(14454004)(6506007)(53546011)(36756003)(81156014)(58126008)(81166006)(8936002)(386003)(25786009)(2906002)(99286004)(76176011)(66446008)(64756008)(66556008)(478600001);DIR:OUT;SFP:1101;SCL:1;SRVR:AM0PR08MB3075;H:AM0PR08MB3140.eurprd08.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;A:1;MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: rgsXr0nwt4juDbWPTx/5H1eDVMQb67K+YjN1hQ+EZnKqRbIlkkxkJF5ScZr0VBUrsESW8QBp3FLNVuiVNydxQpCthRyqTI5HZKiNxPBYESdiyt8HnUJ6l/7bbXWSr/Rtm9CQFcCmgZftjO+W6rru8uy9YOmOyILx0TukR5/hgQbbCknEwSV54HB9tqZZ2uft16TgdiCvqa4TCaI3+ZAzj1W+brWQDRrbsBRLmpG4k7ixdBNLQ1LN305mjrv8bY0CNvB8ysgDHPZHc+mkukHfABG5VkvuGXHWuAd6E7C0txH9DWusWwQfeQr9mWRBrFNUmcaxdigRk08Zhk77WgYZ6CPxlyZkLZ0ypcczwZmlpYrkJ+6HzxbHncrr0dj6cbynLV+xc5xfdV5D4kMLfCNt+u+8FOZEtoSdgGQKOIH3Se0GX1QCkFAcrx9lA71BN3Dz x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Richard.Sandiford@arm.com; Return-Path: Richard.Sandiford@arm.com X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT028.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: e99a992e-e01c-4d1a-5cf5-08d761f9bbda X-IsSubscribed: yes X-SW-Source: 2019-11/txt/msg00288.txt.bz2 Richard Biener writes: > On Tue, Oct 29, 2019 at 6:05 PM Richard Sandiford > wrote: >> >> The BB vectoriser picked vector types in the same way as the loop >> vectoriser: it picked a vector mode/size for the region and then >> based all the vector types off that choice. This meant we could >> end up trying to use vector types that had too many elements for >> the group size. >> >> The main part of this patch is therefore about passing the SLP >> group size down to routines like get_vectype_for_scalar_type and >> ensuring that each vector type in the SLP tree is chosen wrt the >> group size. That part in itself is pretty easy and mechanical. >> >> The main warts are: >> >> (1) We normally pick a STMT_VINFO_VECTYPE for data references at an >> early stage (vect_analyze_data_refs). However, nothing in the >> BB vectoriser relied on this, or on the min_vf calculated from it. >> I couldn't see anything other than vect_recog_bool_pattern that >> tried to access the vector type before the SLP tree is built. > > So can you not set STMT_VINFO_VECTYPE for data refs with BB vectorization > then? Yeah, the patch stops us from setting it during vect_analyze_data_refs. We still need to set it later when building the SLP tree, just like we do for other statements. >> (2) It's possible for the same statement to be used in the groups of >> different sizes. Taking the group size into account meant that >> we could try to pick different vector types for the same statement. > > That only happens when we have multiple SLP instances though > (entries into the shared SLP graph). Yeah. > It probably makes sense to keep handling SLP instances sharing stmts > together for costing reasons but one issue is that for disjunct pieces > (in the same BB) disqualifying one cost-wise disqualifies all. So at > some point during analysis (which should eventually cover more than a > single BB) we want to split the graph. It probably doesn't help the > above case. Yeah, sounds like there are two issues: one with sharing stmt_vec_infos between multiple SLP nodes, and one with sharing SLP child nodes between multiple parent nodes. (2) comes from the first, but I guess failing based on costs is more about the second. >> This problem should go away with the move to doing everything on >> SLP trees, where presumably we would attach the vector type to the >> SLP node rather than the stmt_vec_info. Until then, the patch just >> uses a first-come, first-served approach. > > Yeah, I ran into not having vectype on SLP trees with invariants/externals > as well. I suppose you didn't try simply adding that to the SLP tree > and pushing/popping it like we push/pop the def type? No, didn't try that. Maybe it would be worth a go, but it seems like it could be a rabbit hole. > Assigning the vector types should really happen in vectorizable_* > and not during SLP build itself btw. Agree we need to improve the way this is handled, but delaying it to vectorizable_* sounds quite late. Maybe it should be a more global decision, since the vector types for each vectorizable_* have to be compatible and it's not obvious which routine should get first choice. > Your update-all-shared-vectypes thing looks quadratic to me :/ Should be amortised linear. The statements in a DR group always have the same vectype. When we want to change the vector type of one statement, we change it for all statements if possible or fail if we can't. Thanks, Richard