From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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-Archive: List-Post: List-Help: Sender: gcc-patches-owner@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 11:10:00 -0000 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: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2014-09/txt/msg01040.txt.bz2 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: 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; } 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