ptx preliminary address space fixes [3/4]

Bernd Schmidt
Fri Sep 12 11:10:00 GMT 2014

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), 
+             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
   <address-space-5> unsigned int
make_vector_type makes
   <address-space-5> vector(2) unsigned int
rather than
   <address-space-5> vector(2) <address-space-5> 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?


More information about the Gcc-patches mailing list