From patchwork Wed Sep 5 11:50:28 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Stubbs X-Patchwork-Id: 966339 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-485175-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="HweSyHpj"; 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 4252Bj5WYQz9s5c for ; Wed, 5 Sep 2018 21:52:45 +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=f2jCStKvRB0O8wGJFCwzzxhUAa3O/ PcSC7tzJdPWPU/WjDyli6wGhUcnHxogMmD4Sl1yZ0Pz1Kz8DMKoMdlDtITJ5iE+y 7cYZbsUtgpsAJu6KYn5JBfWJaHvu+BT7WPBBedQqGNGsYz/aS+k+1FmvMeAuYC2K ggtZA3O//L8t40= 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=NysX/dyGYW7oRAo2eU3HtTnoi+o=; b=Hwe SyHpj8Xa5kyrMiqKJiQ9HbBNMgNQCHBZrJGeKVOYqcn/VFsRubEytln8d6rSsLO1 SUjJ5x68O62pt+gYdaZUi/hRpBahYIUKYcoHR1nw2BT14y55O9ZOGbUUv4VDwqvr XSr2h5UvvM2HWBMRRr8wQJjr2Q6jgF9KBttTrtRE= Received: (qmail 90619 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 90496 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=stick, caches 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 1fxWKj-0004Yd-If for gcc-patches@gcc.gnu.org; Wed, 05 Sep 2018 07:50:56 -0400 Received: from relay1.mentorg.com ([192.94.38.131]:45451) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fxWKj-0004Xp-9X for gcc-patches@gcc.gnu.org; Wed, 05 Sep 2018 07:50:53 -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 1fxWKi-0005kj-Eo from Andrew_Stubbs@mentor.com for gcc-patches@gcc.gnu.org; Wed, 05 Sep 2018 04:50:52 -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:48 +0100 From: To: Subject: [PATCH 13/25] Create TARGET_DISABLE_CURRENT_VECTOR_SIZE Date: Wed, 5 Sep 2018 12:50:28 +0100 Message-ID: <85da45b3271492b67b7f2a6f9474ce7a153e200c.1536144068.git.ams@codesourcery.com> 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 This feature probably ought to be reworked as a proper target hook, but I would like to know if this is the correct solution to the problem first. The problem is that GCN vectors have a fixed number of elements (64) and the vector size varies with element size. E.g. V64QI is 64 bytes and V64SI is 256 bytes. This is a problem because GCC has an assumption that a) vector registers are fixed size, and b) if there are multiple vector sizes you want to pick one size and stick with it for the whole function. This is a problem in various places, but mostly it's not fatal. However, get_vectype_for_scalar_type caches the vector size for the first type it encounters and then tries to apply that to all subsequent vectors, which completely destroys vectorization. The caching feature appears to be an attempt to cope with AVX having a different vector size to other x86 vector options. This patch simply disables the cache so that it must ask the backend for the preferred mode for every type. 2018-09-05 Andrew Stubbs gcc/ * tree-vect-stmts.c (get_vectype_for_scalar_type): Implement TARGET_DISABLE_CURRENT_VECTOR_SIZE. --- gcc/tree-vect-stmts.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c index 607a2bd..8875201 100644 --- a/gcc/tree-vect-stmts.c +++ b/gcc/tree-vect-stmts.c @@ -9945,9 +9945,12 @@ get_vectype_for_scalar_type (tree scalar_type) tree vectype; vectype = get_vectype_for_scalar_type_and_size (scalar_type, current_vector_size); +/* FIXME: use a proper target hook or macro. */ +#ifndef TARGET_DISABLE_CURRENT_VECTOR_SIZE if (vectype && known_eq (current_vector_size, 0U)) current_vector_size = GET_MODE_SIZE (TYPE_MODE (vectype)); +#endif return vectype; }