Re: ptx preliminary address space fixes [1/4]

[Richard Biener <richard dot guenther at gmail dot com>]

On Thu, Sep 11, 2014 at 12:11 PM, Bernd Schmidt <bernds@codesourcery.com> wrote:
> I'm getting ready to submit the ptx port and the various changes that are
> necessary for it. To start with, here are some patches to deal with address
> space issues.
>
> ptx has the concept of an implicit address space: everything (objects on the
> stack as well as constant data and global variables) lives in its own
> address space. These are applied by a lower-as pass which I'll submit later.
>
> Since address spaces are more pervasive than on other targets and can show
> up in places the compiler doesn't yet expect them (such as local variables),
> this uncovers a few bugs in the optimizers. These are typically of the kind
> where we recreate a memory reference and aren't quite careful enough to
> preserve the existing address space.
>
> The first patch below just introduces a utility function that the following
> patches will use.  All were bootstrapped and tested together on
> x86_64-linux. Ok?

+tree
+apply_as_to_type (tree type, addr_space_t as)
+{
+  int quals = TYPE_QUALS_NO_ADDR_SPACE (type);
+  if (!ADDR_SPACE_GENERIC_P (as))
+    quals |= ENCODE_QUAL_ADDR_SPACE (as);
+  type = build_qualified_type (type, quals);

please optimize the case of quals == TYPE_QUALS (type).

+  if (TREE_CODE (type) == ARRAY_TYPE)
+    TREE_TYPE (type) = apply_as_to_type (TREE_TYPE (type), as);

why is this necessary for ARRAY_TYPE but not for sth like
a RECORD_TYPE or a POINTER_TYPE?

[having address-spaces on types rather than decls and (indirect)
memory references seems odd anyway - that is, as far as the
middle-/back-end
is concerned]

The name apply_as_to_type looks odd to me - other address-space
related functions use addr_space - can you change it to that please?

Thanks,
Richard.

>
> Bernd