From patchwork Wed Sep 5 11:50:29 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Stubbs X-Patchwork-Id: 966338 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-485174-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="yi0fI5Un"; 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 4252BT1FwTz9s5c for ; Wed, 5 Sep 2018 21:52:32 +1000 (AEST) 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:subject:date:message-id:in-reply-to:references:mime-version :content-type; q=dns; s=default; b=sKenAJJRccEWxM0h9vvqfVrSqNzlN f227BItH3dv/sn+J62ZSRM16U8saOg3qdDsgAxccMCadi0MzGU7T0KrRm3rQHIs+ Pqd0dp1QygYi3uXGf9dt8Rm4m0+Yr2DPySJdeJBdMskrinn55FN7t2K8U/2UXwo6 zegm+wozUZd298= 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:subject:date:message-id:in-reply-to:references:mime-version :content-type; s=default; bh=4YGcTn58IauYaDvmogl75gQNQvc=; b=yi0 fI5Un+rq4eaHvYu/BI6Cemo0+0zQuYYXYMjvmboNFs8cDamP3uVVuJUmeLTdIztI DD1mlb0UhvsuKc1nXkYYBb/phzMIJrlU/oRl/w8p5CreGoXcwx7+oBzATvqzD8I1 7dLElIqvfsGZusRuEnMoCgh5r9FG5d1Apss+lR+Q= Received: (qmail 90575 invoked by alias); 5 Sep 2018 11:51:00 -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 90488 invoked by uid 89); 5 Sep 2018 11:50:59 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-24.7 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3 autolearn=ham version=3.3.2 spammy= X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (208.118.235.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 05 Sep 2018 11:50:58 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fxWKm-0004eI-2S for gcc-patches@gcc.gnu.org; Wed, 05 Sep 2018 07:50:56 -0400 Received: from relay1.mentorg.com ([192.94.38.131]:45455) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fxWKl-0004cp-Pp for gcc-patches@gcc.gnu.org; Wed, 05 Sep 2018 07:50:55 -0400 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=svr-ies-mbx-01.mgc.mentorg.com) by relay1.mentorg.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) id 1fxWKk-0005l9-Uc from Andrew_Stubbs@mentor.com for gcc-patches@gcc.gnu.org; Wed, 05 Sep 2018 04:50:54 -0700 Received: from build6-trusty-cs.sje.mentorg.com (137.202.0.90) by svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 5 Sep 2018 12:50:50 +0100 From: To: Subject: [PATCH 14/25] Disable inefficient vectorization of elementwise loads/stores. Date: Wed, 5 Sep 2018 12:50:29 +0100 Message-ID: In-Reply-To: References: MIME-Version: 1.0 X-detected-operating-system: by eggs.gnu.org: Windows NT kernel [generic] [fuzzy] X-Received-From: 192.94.38.131 If the autovectorizer tries to load a GCN 64-lane vector elementwise then it blows away the register file and produces horrible code. This patch simply disallows elementwise loads for such large vectors. Is there a better way to disable this in the middle-end? 2018-09-05 Julian Brown gcc/ * tree-vect-stmts.c (get_load_store_type): Don't use VMAT_ELEMENTWISE loads/stores with many-element (>=64) vectors. --- gcc/tree-vect-stmts.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c index 8875201..a333991 100644 --- a/gcc/tree-vect-stmts.c +++ b/gcc/tree-vect-stmts.c @@ -2452,6 +2452,26 @@ get_load_store_type (stmt_vec_info stmt_info, tree vectype, bool slp, *memory_access_type = VMAT_CONTIGUOUS; } + /* FIXME: Element-wise accesses can be extremely expensive if we have a + large number of elements to deal with (e.g. 64 for AMD GCN) using the + current generic code expansion. Until an efficient code sequence is + supported for affected targets instead, don't attempt vectorization for + VMAT_ELEMENTWISE at all. */ + if (*memory_access_type == VMAT_ELEMENTWISE) + { + poly_uint64 nelements = TYPE_VECTOR_SUBPARTS (vectype); + + if (maybe_ge (nelements, 64)) + { + if (dump_enabled_p ()) + dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location, + "too many elements (%u) for elementwise accesses\n", + (unsigned) nelements.to_constant ()); + + return false; + } + } + if ((*memory_access_type == VMAT_ELEMENTWISE || *memory_access_type == VMAT_STRIDED_SLP) && !nunits.is_constant ())