On Thu, Sep 11, 2014 at 12:11 PM, Bernd Schmidt <ber...@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
