From patchwork Mon Nov 4 15:27:58 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Sandiford X-Patchwork-Id: 1189007 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-512330-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="D7Ic451o"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 476GtX5X0Fz9sP3 for ; Tue, 5 Nov 2019 02:29:23 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:references:date:in-reply-to:message-id :mime-version:content-type; q=dns; s=default; b=vnPLcWSM8AeFKSAE wmawhlLr9Y+KMFzfKiF2vcoQg79xZQmIIX8h3aEw7GrsLTx4tch82k/C8mJbYtzg /OPzS2DPGXTtHNSlf0hYrtJQ0mWrXOOjuDgvBetSygnCVcIOWuyONdUVbfZBG8ot 6zlkgqfvHsNYHwxdiSHexIFceGE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:references:date:in-reply-to:message-id :mime-version:content-type; s=default; bh=rfCLfmBAZAflH0WBNsyIru zRC50=; b=D7Ic451ortw5LDNtwQXSafcEWhL3pMZc6SpGXxOk2WKm6LG7wX3Ure 1Bqlp606zHWtV2EHjF5EO1Klhi7MJzKkOfM/ZMcEb24gfDEz4470bddVhop4O7Fp LUbpkBKBjAfsCDk87XvBvhpUWqFwrqqR4gkqOlPe83iIKeuCuOhGU= Received: (qmail 51444 invoked by alias); 4 Nov 2019 15:28:07 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 51182 invoked by uid 89); 4 Nov 2019 15:28:05 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-9.6 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_2, GIT_PATCH_3, SPF_PASS autolearn=ham version=3.3.1 spammy=unlimited, prefers X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.110.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 04 Nov 2019 15:28:02 +0000 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 1FABA1FB; Mon, 4 Nov 2019 07:28:00 -0800 (PST) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.126]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8324A3F719; Mon, 4 Nov 2019 07:27:59 -0800 (PST) From: Richard Sandiford To: gcc-patches@gcc.gnu.org Mail-Followup-To: gcc-patches@gcc.gnu.org, andre.simoesdiasvieira@arm.com, richard.sandiford@arm.com Cc: andre.simoesdiasvieira@arm.com Subject: [2/4] Check the VF is small enough for an epilogue loop References: Date: Mon, 04 Nov 2019 15:27:58 +0000 In-Reply-To: (Richard Sandiford's message of "Mon, 04 Nov 2019 15:23:07 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 X-IsSubscribed: yes The number of iterations of an epilogue loop is always smaller than the VF of the main loop. vect_analyze_loop_costing was taking this into account when deciding whether the loop is cheap enough to vectorise, but that has no effect with the unlimited cost model. We need to use a separate check for correctness as well. This can happen if the sizes returned by autovectorize_vector_sizes happen to be out of order, e.g. because the target prefers smaller vectors. It can also happen with later patches if two vectorisation attempts happen to end up with the same VF. 2019-11-04 Richard Sandiford gcc/ * tree-vect-loop.c (vect_analyze_loop_2): When vectorizing an epilogue loop, make sure that the VF is small enough or that the epilogue loop can be fully-masked. Index: gcc/tree-vect-loop.c =================================================================== --- gcc/tree-vect-loop.c 2019-11-04 15:17:35.924940111 +0000 +++ gcc/tree-vect-loop.c 2019-11-04 15:17:50.736838681 +0000 @@ -2142,6 +2142,16 @@ vect_analyze_loop_2 (loop_vec_info loop_ " support peeling for gaps.\n"); } + /* If we're vectorizing an epilogue loop, we either need a fully-masked + loop or a loop that has a lower VF than the main loop. */ + if (LOOP_VINFO_EPILOGUE_P (loop_vinfo) + && !LOOP_VINFO_FULLY_MASKED_P (loop_vinfo) + && maybe_ge (LOOP_VINFO_VECT_FACTOR (loop_vinfo), + LOOP_VINFO_VECT_FACTOR (orig_loop_vinfo))) + return opt_result::failure_at (vect_location, + "Vectorization factor too high for" + " epilogue loop.\n"); + /* Check the costings of the loop make vectorizing worthwhile. */ res = vect_analyze_loop_costing (loop_vinfo); if (res < 0)