From patchwork Mon Nov 4 17:11:48 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: 1189057 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-512348-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="xgUkEcCN"; 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 476K8z63dhz9sNx for ; Tue, 5 Nov 2019 04:12:02 +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 :subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type; q=dns; s=default; b=PPA70TNIt9CM0opSW BN+NT4YzMSM+/LGiTITeC3Um0JQz+iEZyU6Y/ZjVzEVCZM5HvZBW9BFax4KNq4Ce DnhIgiDIjOAYqJFIm/aOdqjgx5L8B9vJgHYbjrB3zJHsgC9ZyQ/MY96vg5ruY6VP RPDnQUlWeDFrRF4Q2cJsQKUZ3w= 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 :subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type; s=default; bh=Sxj6YknDIICQEiiQwLwAJ0C Zmgw=; b=xgUkEcCNuOwD22hjppPbqN0A8YQtlWU/TS2pqgQII3RoGTSXENRFLg8 lxFEvakIPm+XNqF55ljK4UymZJo92uCHGS8Kk8bseYrsbDCXbJS18OHeD5PRIeHu 79kLVPgq3fv1G0mAVTEi5UM0C/lhekLoynPsxoqtjJ7kErIjWcSo= Received: (qmail 76211 invoked by alias); 4 Nov 2019 17:11:54 -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 76196 invoked by uid 89); 4 Nov 2019 17:11:54 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-24.2 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= 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 17:11:52 +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 F025C328; Mon, 4 Nov 2019 09:11:50 -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 4568E3F71A; Mon, 4 Nov 2019 09:11:50 -0800 (PST) Subject: [PATCH][vect] Disable vectorization of epilogues for loops with SIMDUID set To: Jakub Jelinek Cc: Richard Biener , gcc-patches , richard.sandiford@arm.com, tobias@codesourcery.com References: <8be5d0a6-e14b-42af-6b46-738e5b760212@arm.com> <1f9dca66-d8ff-9b80-75b4-98df06e73b96@arm.com> <20191031165841.GL4650@tucnak> From: "Andre Vieira (lists)" Message-ID: <63635e04-3faa-9b89-ca42-0a3b190f4106@arm.com> Date: Mon, 4 Nov 2019 17:11:48 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20191031165841.GL4650@tucnak> X-IsSubscribed: yes Hi, I was using loop->simdlen to detect whether it was a SIMD loop and I don't believe that was correct, as can be witnessed by the mass failures in libgomp. My apologies for not running this, didn't think of it! I found that these were failing because we do not handle vectorization of epilogues correctly when SIMDUID is set. For now Jakub and I agreed to disable epilogue vectorization for loops where SIMDUID is set until we have fixed this. See further comments inline. I bootstrapped it on aarch64 and x86_64, ran libgomp on both. This OK for trunk? Cheers, Andre gcc/ChangeLog: 2019-11-04 Andre Vieira * tree-vect-loop.c (vect_analyze_loop): Disable epilogue vectorization if loop->simduid is non null. On 31/10/2019 16:58, Jakub Jelinek wrote: > FAIL: libgomp.c/../libgomp.c-c++-common/loop-1.c execution test > FAIL: libgomp.c/examples-4/simd-3.c execution test > FAIL: libgomp.c/pr58392.c execution test > FAIL: libgomp.c/scan-13.c execution test > FAIL: libgomp.c/scan-17.c execution test > FAIL: libgomp.c/scan-19.c execution test > FAIL: libgomp.c/scan-20.c execution test > FAIL: libgomp.c/simd-10.c execution test > FAIL: libgomp.c/simd-12.c execution test > FAIL: libgomp.c/simd-13.c execution test > FAIL: libgomp.c/simd-6.c execution test > FAIL: libgomp.c++/../libgomp.c-c++-common/loop-1.c execution test > FAIL: libgomp.c++/simd-8.C execution test > FAIL: libgomp.fortran/examples-4/simd-3.f90 -O1 execution test > FAIL: libgomp.fortran/examples-4/simd-3.f90 -O2 execution test > FAIL: libgomp.fortran/examples-4/simd-3.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test > FAIL: libgomp.fortran/examples-4/simd-3.f90 -O3 -g execution test > FAIL: libgomp.fortran/examples-4/simd-3.f90 -Os execution test > FAIL: libgomp.fortran/nestedfn5.f90 -O1 execution test > FAIL: libgomp.fortran/nestedfn5.f90 -O2 execution test > FAIL: libgomp.fortran/nestedfn5.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test > FAIL: libgomp.fortran/nestedfn5.f90 -O3 -g execution test > FAIL: libgomp.fortran/nestedfn5.f90 -Os execution test These should go away now, but we should revisit SIMDUID and epilogue vectorization later. I tried to look into it, but I am afraid I know very little about SIMD loops to figure out how to make this work. > > On i686-linux, I also see newly > FAIL: gcc.dg/vect/vect-epilogues.c -flto -ffat-lto-objects scan-tree-dump vect "LOOP EPILOGUE VECTORIZED" > FAIL: gcc.dg/vect/vect-epilogues.c scan-tree-dump vect "LOOP EPILOGUE VECTORIZED" > and in libgomp just These, just like for arm should be skipped for i686, I suspect it doesn't know how to vectorize for lower VF's. Could someone add the appropriate skip target triple for i686? > FAIL: libgomp.c/examples-4/simd-3.c execution test > FAIL: libgomp.c/scan-13.c execution test > FAIL: libgomp.c/scan-17.c execution test > FAIL: libgomp.fortran/examples-4/simd-3.f90 -O1 execution test > FAIL: libgomp.fortran/examples-4/simd-3.f90 -O2 execution test > FAIL: libgomp.fortran/examples-4/simd-3.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test > FAIL: libgomp.fortran/examples-4/simd-3.f90 -O3 -g execution test > FAIL: libgomp.fortran/examples-4/simd-3.f90 -Os execution test Same as the other libgomp tests. Should go away now. diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c index fa873e9b435037e5a81dda6615cab809d2d4de48..d3a0fa015332dbcccf84bc68531dc1e49550cc19 100644 --- a/gcc/tree-vect-loop.c +++ b/gcc/tree-vect-loop.c @@ -2383,10 +2383,11 @@ vect_analyze_loop (class loop *loop, loop_vec_info orig_loop_vinfo, poly_uint64 lowest_th = 0; unsigned vectorized_loops = 0; - /* Only vectorize epilogues if PARAM_VECT_EPILOGUES_NOMASK is enabled, this - is not a simd loop and it is the most inner loop. */ + /* Only vectorize epilogues if PARAM_VECT_EPILOGUES_NOMASK is enabled, + SIMDLEN is not set, SIMDUID is not set and this is the most inner loop. + TODO: Enable epilogue vectorization for loops with SIMDUID set. */ bool vect_epilogues - = !loop->simdlen && loop->inner == NULL + = loop->simdlen == 0 && loop->simduid == NULL_TREE && loop->inner == NULL && PARAM_VALUE (PARAM_VECT_EPILOGUES_NOMASK); while (1) {