From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa4.mentor.iphmx.com (esa4.mentor.iphmx.com [68.232.137.252]) by sourceware.org (Postfix) with ESMTPS id 7CC983858C20 for ; Tue, 11 Oct 2022 11:53:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7CC983858C20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="5.95,176,1661846400"; d="scan'208";a="84481793" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa4.mentor.iphmx.com with ESMTP; 11 Oct 2022 03:53:35 -0800 IronPort-SDR: NaIYM2VqKWodi8JluNAOZfuk0rRd2y/uKPw7r0SGrSqVe+mbKA0nfB2jZU/ZKcOFATO2EDajLv i81CaClJH/hYu6NmUYKPEM0HYoaIZTvOqMMHntrdeXB7GMzhZgkts8pR+veo2BBjbvTWDMZvS+ 1aMkjHCgrwa5cwb43ylu1mrafJQEhL9AOMwZX8lZvvwzYRizSZiilUTIDsYZTUtI3Pns3i7cKU AkJLiqu8b2Ru2LJjsF1C3PUTtnVA0rKHhvopCxv3r7iXIN+6+TD98r/FXL5IdpnzpKzGmssQGJ O5A= Message-ID: <00e7c525-cc0d-5144-d95c-573f75657e30@codesourcery.com> Date: Tue, 11 Oct 2022 12:53:30 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.3.2 Subject: Re: [committed 0/6] amdgcn: Add V32, V16, V8, V4, and V2 vectors Content-Language: en-GB To: Richard Biener CC: References: From: Andrew Stubbs In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: SVR-IES-MBX-07.mgc.mentorg.com (139.181.222.7) To svr-ies-mbx-11.mgc.mentorg.com (139.181.222.11) X-Spam-Status: No, score=-8.2 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,NICE_REPLY_A,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: On 11/10/2022 12:29, Richard Biener wrote: > On Tue, Oct 11, 2022 at 1:03 PM Andrew Stubbs wrote: >> >> This patch series adds additional vector sizes for the amdgcn backend. >> >> The hardware supports any arbitrary vector length up to 64-lanes via >> masking, but GCC cannot (yet) make full use of them due to middle-end >> limitations. Adding smaller "virtual" vector sizes increases the >> complexity of the backend a little, but opens up optimization >> opportunities for the current middle-end implementation somewhat. In >> particular, it enables many more cases of SLP optimization. >> >> The patchset gives aproximately 100 addtional test PASS and a few extra >> FAIL. However, the failures are not new issues, but rather existing >> problems that did not show up because the code did not previously >> vectorize. Expanding the testcase to allow 64-lane vectors shows the >> same problems there. >> >> I shall backport these patches to the OG12 branch shortly. > > I suppose until you change the related_vector_mode hook the PR107096 issue > will not hit you but at least it's then latent ... How do you mean, change it? static opt_machine_mode gcn_related_vector_mode (machine_mode vector_mode, scalar_mode element_mode, poly_uint64 nunits) { int n = nunits.to_constant (); if (n == 0) n = GET_MODE_NUNITS (vector_mode); return VnMODE (n, element_mode); } It returns what it's asked for, always matching the number of lanes (not the bitsize), which is most likely the most natural for GCN. Andrew