From patchwork Fri Sep 12 11:09:14 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bernd Schmidt X-Patchwork-Id: 388585 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org 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 9C6FC1400AA for ; Fri, 12 Sep 2014 21:10:36 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; q=dns; s= default; b=dv2DdYmNankSdtY+4ARxiXT9vu2lcF8scipGjmqzooz3ELb24wsct g7aw85AYCYIVhFiRKR7d6me0rx1Y/KpB0XkJGvoXeQ91va3OO3lFo+GnrBcS7Dy0 olVgNdR2XqBPm1kXDbVOXmrTLkGXPRLpUzQUTqZxRppJ9xnozYKgsU= 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 :message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; s=default; bh=1Bllx6sbVr06Vetm8QQ0T9dTpKY=; b=Nup9v39IID1czC53dGZELgOYqjP7 7WwHgiOFMt30mNZMjwAPJO0QASKLr0rRd/aAPfFHlAkOK8J4OlOghDwyWDaX8lOG igt6X0AgVFINAzESHn62VI48NE1c8MRa7djh5kh4PqRrOXU4xE19T3kCS3Na3lL4 8/oo0UQLmD7AFwg= Received: (qmail 2859 invoked by alias); 12 Sep 2014 11:10:29 -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 2844 invoked by uid 89); 12 Sep 2014 11:10:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL, BAYES_00 autolearn=no version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 12 Sep 2014 11:10:27 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1XSOkB-0000KV-4j from Bernd_Schmidt@mentor.com ; Fri, 12 Sep 2014 04:10:24 -0700 Received: from [127.0.0.1] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.3.181.6; Fri, 12 Sep 2014 12:10:21 +0100 Message-ID: <5412D45A.5080705@codesourcery.com> Date: Fri, 12 Sep 2014 13:09:14 +0200 From: Bernd Schmidt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.8.0 MIME-Version: 1.0 To: Richard Biener CC: GCC Patches Subject: Re: ptx preliminary address space fixes [3/4] References: <54117586.8050503@codesourcery.com> In-Reply-To: On 09/11/2014 01:39 PM, Richard Biener wrote: > Seeing this it would be nice to abstract away the exact place we store > the address-space in a memory reference. So - can you add a helper > reference_addr_space () please? Thus do > > addr_space_t as = reference_addr_space (scalar_dest); Ok, no problem. > but then I wonder why not simply build the correct vector types > in the first place in vect_analyze_data_refs? We do, kind of. But there are two problems, the first one addressed here in the patch: - data_ref = build2 (MEM_REF, TREE_TYPE (vec_oprnd), dataref_ptr, + data_ref = build2 (MEM_REF, vectype, dataref_ptr, We use the wrong vector type (vectype has the right address space, but vec_oprnd is an SSA_NAME). The second problem is our reprentation of vector types. When given unsigned int make_vector_type makes vector(2) unsigned int rather than vector(2) unsigned int Since we use elem_type in a few ways in tree_vectorizable_stmt, that looks like it would cause problems, but it probably can be addressed in a simpler way than what I originally had: Let me know what you prefer. > Or apply the addr-space to the memory reference with a new helper > reference_apply_addr_space > > - data_ref = build2 (MEM_REF, TREE_TYPE (vec_oprnd), dataref_ptr, > dataref_offset > ? dataref_offset > : build_int_cst (reference_alias_ptr_type > .. > reference_apply_addr_space (data_ref, as); > > at least that's how it's abstracted on the RTL side. I think I'd prefer > if things would be working that way on the tree level, too. I'm adapting my other patches to use such a function, but in this particular case I think it would be best to fix up the types in advance since we build accesses in several places and especially vectorizable_load also seems to create operations on the pointer type. Are you ok with that? Bernd Index: gomp-4_0-branch/gcc/tree-vect-stmts.c =================================================================== --- gomp-4_0-branch.orig/gcc/tree-vect-stmts.c +++ gomp-4_0-branch/gcc/tree-vect-stmts.c @@ -5037,7 +5037,8 @@ vectorizable_store (gimple stmt, gimple_ return false; } - elem_type = TREE_TYPE (vectype); + elem_type = apply_addr_space_to_type (TREE_TYPE (vectype), + TYPE_ADDR_SPACE (vectype)); vec_mode = TYPE_MODE (vectype); /* FORNOW. In some cases can vectorize even if data-type not supported @@ -5692,7 +5693,8 @@ vectorizable_load (gimple stmt, gimple_s if (!STMT_VINFO_DATA_REF (stmt_info)) return false; - elem_type = TREE_TYPE (vectype); + elem_type = apply_addr_space_to_type (TREE_TYPE (vectype), + TYPE_ADDR_SPACE (vectype)); mode = TYPE_MODE (vectype); /* FORNOW. In some cases can vectorize even if data-type not supported The other alternative is to fix up make_vector_type. That could look like this: Index: gomp-4_0-branch/gcc/tree.c =================================================================== --- gomp-4_0-branch.orig/gcc/tree.c +++ gomp-4_0-branch/gcc/tree.c @@ -9470,9 +9470,13 @@ make_vector_type (tree innertype, int nu inner type. Use it to build the variant we return. */ if ((TYPE_ATTRIBUTES (innertype) || TYPE_QUALS (innertype)) && TREE_TYPE (t) != innertype) - return build_type_attribute_qual_variant (t, - TYPE_ATTRIBUTES (innertype), - TYPE_QUALS (innertype)); + { + t = build_type_attribute_qual_variant (t, + TYPE_ATTRIBUTES (innertype), + TYPE_QUALS (innertype)); + TREE_TYPE (t) = apply_addr_space_to_type (TREE_TYPE (t), + TYPE_ADDR_SPACE (innertype)); + } return t; }