From patchwork Mon Nov 11 17:59:00 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Andre Vieira (lists)" X-Patchwork-Id: 1193047 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-512973-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="pni48AAn"; 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 47BdtC4fpcz9s4Y for ; Tue, 12 Nov 2019 04:59:13 +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:to:cc :from:subject:message-id:date:mime-version:content-type; q=dns; s=default; b=kWKnU3rszhpTcWFN2TO0TsKHeVNwPEDMWOqJbKPfdeyCB7j0df yCfqlljhN7Q+N9+HumPJsbU98hbiEVktpFY1fKguaz3py51NCsXqcBgC7asRfStB O3+9oC8ZcoifGdnMMPk7Wn5uUGJ6eFkVyyBuMKI80CkCYZ/AI3tA2RuQU= 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:to:cc :from:subject:message-id:date:mime-version:content-type; s= default; bh=OpPYJ0JZFvr5PyAi4eGUvLeXZ7w=; b=pni48AAnyU6AOhq9/cGy yviOlb/mvCgcmkvwtUz73weg994tS/0Ou9/JCuJFtu+8qc07aLUBCEWsZgkhBvvs +KPd9OZZdGZCOmFBgrjtgDgv5gWGelu2B58+IkfV2i1NB/ZWyT0HmFc9PwQImhnB vDMg2DlNakv8P8qmK9czW9o= Received: (qmail 61366 invoked by alias); 11 Nov 2019 17:59:05 -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 61358 invoked by uid 89); 11 Nov 2019 17:59:05 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-24.1 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, SPF_PASS autolearn=ham version=3.3.1 spammy=arising 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, 11 Nov 2019 17:59:04 +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 1D29E1FB; Mon, 11 Nov 2019 09:59:02 -0800 (PST) Received: from [10.2.206.37] (e107157-lin.cambridge.arm.com [10.2.206.37]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BB7CE3F534; Mon, 11 Nov 2019 09:59:01 -0800 (PST) To: gcc-patches Cc: Richard Biener From: "Andre Vieira (lists)" Subject: [PATCH][vect]PR92347: Don't overwrite safelen for epilogues Message-ID: <598c816d-e5eb-6c1f-fec4-f2c7ab9e2898@arm.com> Date: Mon, 11 Nov 2019 17:59:00 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 X-IsSubscribed: yes Hi, After during my investigation into the first testcase in PR92347 I noticed that the ICE was arising because the vectorizer was under the assumption it knew how to vectorize the zp call for both the main and epilogues. By the time it got to transform the epilogue vectorizable_simd_clone_call would fail, leading to the eventual ICE. The reason was because the main loop's safelen was set to MAX_INT at time of analysis, but 0 for the epilogue at the time of its transformation. This was because we were copying the loop's safelen to the epilogue after vectorizing the main loop and we set safelen to 0 when we are done vectorizing. This resulted in the epilogue always having safelen set to 0 at transformation time. I believe its safe to assume that if the main loop can assume that it is safe to vectorize between 0 and safelen then so is the epilogue in this context. Bootstrapped x86_64 and aarch64 and ran libgomp. Is this OK for trunk? (If approved can someone commit on my behalf as I'll be away for two weeks?) Cheers, Andre gcc/ChangeLog: 2019-11-11 Andre Vieira * tree-vect-loop.c (vect_transform_loop): Don't overwrite epilogues safelen with 0. gcc/testsuite/ChangeLog: 2019-11-11 Andre Vieira * gcc.dg/vect/pr92347.c: New test. diff --git a/gcc/testsuite/gcc.dg/vect/pr92347.c b/gcc/testsuite/gcc.dg/vect/pr92347.c new file mode 100644 index 0000000000000000000000000000000000000000..f7e6b490c837f209e9a574d6f10e1e2e34e4729e --- /dev/null +++ b/gcc/testsuite/gcc.dg/vect/pr92347.c @@ -0,0 +1,18 @@ +/* Copied from PR 92347. */ +/* { dg-do compile } */ +/* { dg-options "-O1 -fopenmp" } */ +/* { dg-additional-options "-mavx" { target { i?86-*-* x86_64-*-* } } } */ + +int by; + +#pragma omp declare simd +int +zp (int); + +void +qh (int oh) +{ +#pragma omp simd + for (by = 0; by < oh; ++by) + by = zp (by); +} diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c index 78fe6290ee6bf069f7cfaabba466f119e41f39ac..b600d3157457c3180d0456c4f66cbc57012e3c71 100644 --- a/gcc/tree-vect-loop.c +++ b/gcc/tree-vect-loop.c @@ -8587,7 +8587,6 @@ vect_transform_loop (loop_vec_info loop_vinfo) epilogue->simduid = loop->simduid; epilogue->force_vectorize = loop->force_vectorize; - epilogue->safelen = loop->safelen; epilogue->dont_vectorize = false; }