From patchwork Wed Jan 12 10:13:55 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: "Andre Vieira (lists)" X-Patchwork-Id: 1578984 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: bilbo.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.a=rsa-sha256 header.s=default header.b=E7Y/2pqy; dkim-atps=neutral Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=2620:52:3:1:0:246e:9693:128c; helo=sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by bilbo.ozlabs.org (Postfix) with ESMTPS id 4JYk2H4Frpz9sSs for ; Wed, 12 Jan 2022 21:14:47 +1100 (AEDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C1B8038B3439 for ; Wed, 12 Jan 2022 10:14:44 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C1B8038B3439 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1641982484; bh=NnszZZkGETClBr+xdFTOhlT7Ld/W0zLx8gpsBg7a/qA=; h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=E7Y/2pqyU4U6z8Z8H/vcDGcWW4iVvn7zjxc+Wb5Q/Wxwy56O4sMVAPqeOEXpWy+s4 L7WqE6/+SdnskU289zXVsWt323j1dLpSrpp7uV/sfGT6ZxS5ZDJgkmlR/1fnzo/dm5 eOLkx0Rc9Xl9bE4bXI2qfTLdqxTIpMruJQJmyxtg= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 157AE393A416 for ; Wed, 12 Jan 2022 10:13:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 157AE393A416 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A9E8FED1; Wed, 12 Jan 2022 02:13:50 -0800 (PST) Received: from [10.57.11.50] (unknown [10.57.11.50]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1ADF03F5A1; Wed, 12 Jan 2022 02:13:49 -0800 (PST) Message-ID: Date: Wed, 12 Jan 2022 10:13:55 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Content-Language: en-US To: "gcc-patches@gcc.gnu.org" Subject: [vect] PR103971, PR103977: Fix epilogue mode selection for autodetect only X-Spam-Status: No, score=-11.6 required=5.0 tests=BAYES_00, BODY_8BITS, GIT_PATCH_0, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: "Andre Vieira \(lists\) via Gcc-patches" From: "Andre Vieira (lists)" Reply-To: "Andre Vieira \(lists\)" Cc: Richard Sandiford , Richard Biener Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org Sender: "Gcc-patches" Hi, This a fix for the regression caused by '[vect] Re-analyze all modes for epilogues'. The earlier patch assumed there was always at least one other mode than VOIDmode, but that does not need to be the case. If we are dealing with a target that does not define more modes for 'autovectorize_vector_modes', the behaviour before the patch would be to try to create an epilogue for the same autodetected_vector_mode, which unless the target supported partial vectors would always fail. So as a fix I suggest trying to vectorize the epilogue with the preferred_simd_mode for QI, mimicking autovectorize_vector_mode, which will be skipped if it is not a vector_mode (since that already should indicate partial vectors aren't possible) or if no partial vectors are supported and its pessimistic NUNITS is larger than the main loop's VF. Currently bootstrapping and regression testing, otherwise OK for trunk? Can someone verify this fixes the issue for PR103971 on powerpc? gcc/ChangeLog:         * tree-vect-loop.c (vect-analyze-loop): Handle scenario where target         does add autovectorize_vector_modes. diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c index 6ed2b5f8724e5ebf27592f67d7f6bdfe1ebcf512..c81ebc411312e649f9cd954895244c60c928fee1 100644 --- a/gcc/tree-vect-loop.c +++ b/gcc/tree-vect-loop.c @@ -3024,6 +3024,18 @@ vect_analyze_loop (class loop *loop, vec_info_shared *shared) ordering is not guaranteed, so we could end up picking a mode for the main loop that is after the epilogue's optimal mode. */ mode_i = 1; + /* If we only had VOIDmode then push the AUTODETECTED_VECTOR_MODE to see if + an epilogue can be created with that mode. */ + if (vector_modes.length () == 1) + { + machine_mode preferred_mode + = targetm.vectorize.preferred_simd_mode (QImode); + /* If the preferred mode isn't a vector mode we will not be needing an + epilogue. */ + if (!VECTOR_MODE_P (preferred_mode)) + return first_loop_vinfo; + vector_modes.safe_push (preferred_mode); + } bool supports_partial_vectors = partial_vectors_supported_p (); poly_uint64 first_vinfo_vf = LOOP_VINFO_VECT_FACTOR (first_loop_vinfo);