ptx preliminary address space fixes [1/4]

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?


Bernd

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

On 09/11/2014 01:29 PM, Richard Biener wrote:
> +  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?

Still testing whether I actually strictly need it for ARRAY_TYPE 
nowadays (these patches are really old...). However, the TYPE_FIELDS of 
a RECORD_TYPE seem to be mostly ignored once the frontends are done, but 
it's very easy for other parts of the compiler to take the TREE_TYPE of 
an ARRAY_TYPE. Fixing that up is simple and seems like a good thing to 
do for consistency (I notice that maybe I should add VECTOR_TYPE).

For a POINTER_TYPE, it is correct not to modify the pointed-to type. We 
want to express that a variable of that pointer type lives in an address 
space, not that the pointed-to type is different.

> 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?

Will change, and update the other patches accordingly.


Bernd

On Fri, Sep 12, 2014 at 1:15 PM, Bernd Schmidt <bernds@codesourcery.com> wrote:
> On 09/11/2014 01:29 PM, Richard Biener wrote:
>>
>> +  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?
>
>
> Still testing whether I actually strictly need it for ARRAY_TYPE nowadays
> (these patches are really old...). However, the TYPE_FIELDS of a RECORD_TYPE
> seem to be mostly ignored once the frontends are done, but it's very easy
> for other parts of the compiler to take the TREE_TYPE of an ARRAY_TYPE.
> Fixing that up is simple and seems like a good thing to do for consistency
> (I notice that maybe I should add VECTOR_TYPE).

Well, for an access a->b the COMPONENT_REF specifies the type
of the reference which uses the type of the FIELD_DECL...  IVOPTs
for example may produce

 ptr *p = &a->b;
 *p;

from that with ptr * built from TREE_TYPE of that expression.

Btw, a similar type as VECTOR_TYPE is COMPLEX_TYPE.

> For a POINTER_TYPE, it is correct not to modify the pointed-to type. We want
> to express that a variable of that pointer type lives in an address space,
> not that the pointed-to type is different.
>
>> 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?
>
>
> Will change, and update the other patches accordingly.

Thanks,
Richard.

>
> Bernd
>

On 09/12/2014 01:48 PM, Richard Biener wrote:
>> Still testing whether I actually strictly need it for ARRAY_TYPE nowadays
>> (these patches are really old...). However, the TYPE_FIELDS of a RECORD_TYPE
>> seem to be mostly ignored once the frontends are done, but it's very easy
>> for other parts of the compiler to take the TREE_TYPE of an ARRAY_TYPE.
>> Fixing that up is simple and seems like a good thing to do for consistency
>> (I notice that maybe I should add VECTOR_TYPE).
>
> Well, for an access a->b the COMPONENT_REF specifies the type
> of the reference which uses the type of the FIELD_DECL...  IVOPTs
> for example may produce
>
>   ptr *p = &a->b;
>   *p;
>
> from that with ptr * built from TREE_TYPE of that expression.

Yes, but that expression is the COMPONENT_REF. While that may initially 
use the type from the FIELD_DECL, afterwards it is independent from it 
(and types on COMPONENT_REFs and ARRAY_REFs are changed by the lower-as 
pass on ptx).  We're not really looking at the FIELD_DECLs for anything 
important AFAIK.


Bernd

On Fri, Sep 12, 2014 at 1:56 PM, Bernd Schmidt <bernds@codesourcery.com> wrote:
> On 09/12/2014 01:48 PM, Richard Biener wrote:
>>>
>>> Still testing whether I actually strictly need it for ARRAY_TYPE nowadays
>>> (these patches are really old...). However, the TYPE_FIELDS of a
>>> RECORD_TYPE
>>> seem to be mostly ignored once the frontends are done, but it's very easy
>>> for other parts of the compiler to take the TREE_TYPE of an ARRAY_TYPE.
>>> Fixing that up is simple and seems like a good thing to do for
>>> consistency
>>> (I notice that maybe I should add VECTOR_TYPE).
>>
>>
>> Well, for an access a->b the COMPONENT_REF specifies the type
>> of the reference which uses the type of the FIELD_DECL...  IVOPTs
>> for example may produce
>>
>>   ptr *p = &a->b;
>>   *p;
>>
>> from that with ptr * built from TREE_TYPE of that expression.
>
>
> Yes, but that expression is the COMPONENT_REF. While that may initially use
> the type from the FIELD_DECL, afterwards it is independent from it (and
> types on COMPONENT_REFs and ARRAY_REFs are changed by the lower-as pass on
> ptx).  We're not really looking at the FIELD_DECLs for anything important
> AFAIK.

You figured out SRA yourself.  Btw, I still detest the use of a lowering
pass for PTX (changing types in-place even more so).  Maybe you
want to do the lowering on RTL where you can simply adjust the
affected MEMs MEM_ATTRs.  And wouldn't it be nice if you can
do similar things on GIMPLE? ;)

Richard.

>
> Bernd
>

On 09/12/2014 01:48 PM, Richard Biener wrote:
> On Fri, Sep 12, 2014 at 1:15 PM, Bernd Schmidt <bernds@codesourcery.com> wrote:
>> On 09/11/2014 01:29 PM, Richard Biener wrote:
>>>
>>> +  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?
>>
>>
>> Still testing whether I actually strictly need it for ARRAY_TYPE nowadays
>> (these patches are really old...). However, the TYPE_FIELDS of a RECORD_TYPE
>> seem to be mostly ignored once the frontends are done, but it's very easy
>> for other parts of the compiler to take the TREE_TYPE of an ARRAY_TYPE.
>> Fixing that up is simple and seems like a good thing to do for consistency
>> (I notice that maybe I should add VECTOR_TYPE).
>
> Well, for an access a->b the COMPONENT_REF specifies the type
> of the reference which uses the type of the FIELD_DECL...  IVOPTs
> for example may produce
>
>   ptr *p = &a->b;
>   *p;
>
> from that with ptr * built from TREE_TYPE of that expression.
>
> Btw, a similar type as VECTOR_TYPE is COMPLEX_TYPE.

Ok, so testing seems to show that nothing breaks with the ARRAY_TYPE 
special case removed. However, I remembered another reason to do this, 
and it's for consistency with how address spaces are represented in 
other parts of the compiler - specifically, the C frontend.

C has the notion that arrays don't have type qualifiers, so to get the 
address space of an array you'd have to look at the address space of its 
element types. Joseph has in the past rejected patches to fix this 
inconsistency. For other types like structs or vectors (as we saw in the 
tree-vect patch) it's the outermost type that has the address space 
information.

I guess I'll declare myself agnostic, let me know whatever variant you 
want to have here (fixing up all types or not fixing arrays) and I'll 
make a new patch.


Bernd

On Tue, Sep 16, 2014 at 1:24 PM, Bernd Schmidt <bernds@codesourcery.com> wrote:
> On 09/12/2014 01:48 PM, Richard Biener wrote:
>>
>> On Fri, Sep 12, 2014 at 1:15 PM, Bernd Schmidt <bernds@codesourcery.com>
>> wrote:
>>>
>>> On 09/11/2014 01:29 PM, Richard Biener wrote:
>>>>
>>>>
>>>> +  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?
>>>
>>>
>>>
>>> Still testing whether I actually strictly need it for ARRAY_TYPE nowadays
>>> (these patches are really old...). However, the TYPE_FIELDS of a
>>> RECORD_TYPE
>>> seem to be mostly ignored once the frontends are done, but it's very easy
>>> for other parts of the compiler to take the TREE_TYPE of an ARRAY_TYPE.
>>> Fixing that up is simple and seems like a good thing to do for
>>> consistency
>>> (I notice that maybe I should add VECTOR_TYPE).
>>
>>
>> Well, for an access a->b the COMPONENT_REF specifies the type
>> of the reference which uses the type of the FIELD_DECL...  IVOPTs
>> for example may produce
>>
>>   ptr *p = &a->b;
>>   *p;
>>
>> from that with ptr * built from TREE_TYPE of that expression.
>>
>> Btw, a similar type as VECTOR_TYPE is COMPLEX_TYPE.
>
>
> Ok, so testing seems to show that nothing breaks with the ARRAY_TYPE special
> case removed. However, I remembered another reason to do this, and it's for
> consistency with how address spaces are represented in other parts of the
> compiler - specifically, the C frontend.
>
> C has the notion that arrays don't have type qualifiers, so to get the
> address space of an array you'd have to look at the address space of its
> element types. Joseph has in the past rejected patches to fix this
> inconsistency. For other types like structs or vectors (as we saw in the
> tree-vect patch) it's the outermost type that has the address space
> information.
>
> I guess I'll declare myself agnostic, let me know whatever variant you want
> to have here (fixing up all types or not fixing arrays) and I'll make a new
> patch.

Hmm.  How is it with other compositive types like vectors and complex?
It's bad that the middle-end needs to follow a specific frontends need.
Why's the representation tied so closely together?

OTOH that address-spaces are "qualifiers" is an implementation detail
(and maybe not the very best).  So I don't see how the C frontend
needs to view them as qualifiers?

Joseph?

Thanks,
Richard.

>
> Bernd
>
>

On Tue, 16 Sep 2014, Richard Biener wrote:

> Hmm.  How is it with other compositive types like vectors and complex?
> It's bad that the middle-end needs to follow a specific frontends need.
> Why's the representation tied so closely together?

Complex types aren't derived types in C terms; they don't have an element 
type, but a corresponding real type.  Vectors should presumably be treated 
like complex types.  So both can have qualifiers.

> OTOH that address-spaces are "qualifiers" is an implementation detail
> (and maybe not the very best).  So I don't see how the C frontend
> needs to view them as qualifiers?

It's not an implementation detail, it's how TR 18037 defines them, and 
thus how the C front end should represent them in order to follow the 
requirements of TR 18037.

If something different is appropriate on GIMPLE, when GIMPLE gets its own 
type system independent of trees then the lowering could of course change 
this sort of thing.

(I think the fixed-point support, also from TR 18037, would better be 
implemented through lowering from fixed-point types at front-end level to 
special (e.g. saturating) operations on normal types and modes, rather 
than carrying a load of special types and modes through to the back end.)

On 09/16/2014 10:56 PM, Joseph S. Myers wrote:
> On Tue, 16 Sep 2014, Richard Biener wrote:
>
>> Hmm.  How is it with other compositive types like vectors and complex?
>> It's bad that the middle-end needs to follow a specific frontends need.
>> Why's the representation tied so closely together?
>
> Complex types aren't derived types in C terms; they don't have an element
> type, but a corresponding real type.  Vectors should presumably be treated
> like complex types.  So both can have qualifiers.
>
>> OTOH that address-spaces are "qualifiers" is an implementation detail
>> (and maybe not the very best).  So I don't see how the C frontend
>> needs to view them as qualifiers?
>
> It's not an implementation detail, it's how TR 18037 defines them, and
> thus how the C front end should represent them in order to follow the
> requirements of TR 18037.

My position is that standards do not mandate how our internal data 
structures should look like, and we should be striving to make them 
consistent. That means building array types in such a way that address 
spaces (and probably things like constness) are identical between the 
array type and its element type. It would be easy enough to make a 
c_type_quals wrapper function around TYPE_QUALS that returns zero for 
array types, but I would not expect there to really be a need for it.


Bernd

On Tue, 16 Sep 2014, Bernd Schmidt wrote:

> > It's not an implementation detail, it's how TR 18037 defines them, and
> > thus how the C front end should represent them in order to follow the
> > requirements of TR 18037.
> 
> My position is that standards do not mandate how our internal data structures
> should look like, and we should be striving to make them consistent. That

My position is that the structures in the front end should correspond to 
how the language is actually defined, so that the most obvious way of 
accessing some property of an entity in the front end actually gets that 
property as it is defined in the standard, and not something similar but 
confusingly different defined by GCC.  It's the job of genericizing / 
gimplifying to convert from structures that closely correspond to the 
source program and the language standard into ones that are more 
convenient for language-independent processing and code generation.

(That TYPE_MAIN_VARIANT maps an array of qualified type to an array of 
corresponding unqualified type necessitates lots of special cases in the 
front end to avoid applying TYPE_MAIN_VARIANT to array types, since in C 
terms array types are always unqualified and are unrelated to an array of 
corresponding unqualified element type.)

On 09/16/2014 11:18 PM, Joseph S. Myers wrote:

> (That TYPE_MAIN_VARIANT maps an array of qualified type to an array of
> corresponding unqualified type necessitates lots of special cases in the
> front end to avoid applying TYPE_MAIN_VARIANT to array types, since in C
> terms array types are always unqualified and are unrelated to an array of
> corresponding unqualified element type.)

Sounds like you want a c_type_main_variant wrapper then? What exactly 
breaks if you ignore the problem and apply TYPE_MAIN_VARIANT to arrays?


bernd

On Wed, 17 Sep 2014, Bernd Schmidt wrote:

> On 09/16/2014 11:18 PM, Joseph S. Myers wrote:
> 
> > (That TYPE_MAIN_VARIANT maps an array of qualified type to an array of
> > corresponding unqualified type necessitates lots of special cases in the
> > front end to avoid applying TYPE_MAIN_VARIANT to array types, since in C
> > terms array types are always unqualified and are unrelated to an array of
> > corresponding unqualified element type.)
> 
> Sounds like you want a c_type_main_variant wrapper then? What exactly breaks
> if you ignore the problem and apply TYPE_MAIN_VARIANT to arrays?

Anything where the C standard defines something in terms of the 
unqualified versions of types, or the set of qualifiers on a type, 
operates incorrectly (tests compatibility of the wrong types, etc.) if you 
apply TYPE_MAIN_VARIANT to arrays.

On 09/16/2014 02:59 PM, Richard Biener wrote:
> On Tue, Sep 16, 2014 at 1:24 PM, Bernd Schmidt <bernds@codesourcery.com> wrote:
>> Ok, so testing seems to show that nothing breaks with the ARRAY_TYPE special
>> case removed. However, I remembered another reason to do this, and it's for
>> consistency with how address spaces are represented in other parts of the
>> compiler - specifically, the C frontend.
>>
>> C has the notion that arrays don't have type qualifiers, so to get the
>> address space of an array you'd have to look at the address space of its
>> element types. Joseph has in the past rejected patches to fix this
>> inconsistency. For other types like structs or vectors (as we saw in the
>> tree-vect patch) it's the outermost type that has the address space
>> information.
>>
>> I guess I'll declare myself agnostic, let me know whatever variant you want
>> to have here (fixing up all types or not fixing arrays) and I'll make a new
>> patch.
>
> Hmm.  How is it with other compositive types like vectors and complex?
> It's bad that the middle-end needs to follow a specific frontends need.
> Why's the representation tied so closely together?
>
> OTOH that address-spaces are "qualifiers" is an implementation detail
> (and maybe not the very best).  So I don't see how the C frontend
> needs to view them as qualifiers?

So what's the conclusion here? What should I be doing with the patch?


Bernd

On Fri, Sep 26, 2014 at 2:00 PM, Bernd Schmidt <bernds@codesourcery.com> wrote:
> On 09/16/2014 02:59 PM, Richard Biener wrote:
>>
>> On Tue, Sep 16, 2014 at 1:24 PM, Bernd Schmidt <bernds@codesourcery.com>
>> wrote:
>>>
>>> Ok, so testing seems to show that nothing breaks with the ARRAY_TYPE
>>> special
>>> case removed. However, I remembered another reason to do this, and it's
>>> for
>>> consistency with how address spaces are represented in other parts of the
>>> compiler - specifically, the C frontend.
>>>
>>> C has the notion that arrays don't have type qualifiers, so to get the
>>> address space of an array you'd have to look at the address space of its
>>> element types. Joseph has in the past rejected patches to fix this
>>> inconsistency. For other types like structs or vectors (as we saw in the
>>> tree-vect patch) it's the outermost type that has the address space
>>> information.
>>>
>>> I guess I'll declare myself agnostic, let me know whatever variant you
>>> want
>>> to have here (fixing up all types or not fixing arrays) and I'll make a
>>> new
>>> patch.
>>
>>
>> Hmm.  How is it with other compositive types like vectors and complex?
>> It's bad that the middle-end needs to follow a specific frontends need.
>> Why's the representation tied so closely together?
>>
>> OTOH that address-spaces are "qualifiers" is an implementation detail
>> (and maybe not the very best).  So I don't see how the C frontend
>> needs to view them as qualifiers?
>
>
> So what's the conclusion here? What should I be doing with the patch?

If currently address-space support matches up with the C frontend
and the C standard then the middle-end has to cope with that.
In this case, cope with array element types not having address-space
qualifiers.

Richard.

>
> Bernd
>

On 09/26/2014 02:05 PM, Richard Biener wrote:
> If currently address-space support matches up with the C frontend
> and the C standard then the middle-end has to cope with that.
> In this case, cope with array element types not having address-space
> qualifiers.

That's the opposite of what happens. The C frontend makes array element 
types have address-space qualifiers but not the array type.


Bernd

On Fri, Sep 26, 2014 at 2:14 PM, Bernd Schmidt <bernds@codesourcery.com> wrote:
> On 09/26/2014 02:05 PM, Richard Biener wrote:
>>
>> If currently address-space support matches up with the C frontend
>> and the C standard then the middle-end has to cope with that.
>> In this case, cope with array element types not having address-space
>> qualifiers.
>
>
> That's the opposite of what happens. The C frontend makes array element
> types have address-space qualifiers but not the array type.

Ah, ok.  Then the opposite way around ;)

Richard.

>
> Bernd
>
>

On 09/26/2014 02:26 PM, Richard Biener wrote:
> On Fri, Sep 26, 2014 at 2:14 PM, Bernd Schmidt <bernds@codesourcery.com> wrote:
>> On 09/26/2014 02:05 PM, Richard Biener wrote:
>>>
>>> If currently address-space support matches up with the C frontend
>>> and the C standard then the middle-end has to cope with that.
>>> In this case, cope with array element types not having address-space
>>> qualifiers.
>>
>>
>> That's the opposite of what happens. The C frontend makes array element
>> types have address-space qualifiers but not the array type.
>
> Ah, ok.  Then the opposite way around ;)

Ok, so that means that my original patch which updated the element types 
for arrays is in fact the way to go?


Bernd

On Fri, Sep 26, 2014 at 2:28 PM, Bernd Schmidt <bernds@codesourcery.com> wrote:
> On 09/26/2014 02:26 PM, Richard Biener wrote:
>>
>> On Fri, Sep 26, 2014 at 2:14 PM, Bernd Schmidt <bernds@codesourcery.com>
>> wrote:
>>>
>>> On 09/26/2014 02:05 PM, Richard Biener wrote:
>>>>
>>>>
>>>> If currently address-space support matches up with the C frontend
>>>> and the C standard then the middle-end has to cope with that.
>>>> In this case, cope with array element types not having address-space
>>>> qualifiers.
>>>
>>>
>>>
>>> That's the opposite of what happens. The C frontend makes array element
>>> types have address-space qualifiers but not the array type.
>>
>>
>> Ah, ok.  Then the opposite way around ;)
>
>
> Ok, so that means that my original patch which updated the element types for
> arrays is in fact the way to go?

It seems to do both, apply the as to the array _and_ the element type, no?

Thus for arrays you'd need to do (in that old patches terms)

  type = build_variant_type_copy (type);
  TREE_TYPE (type) = apply_as_to_type (TREE_TYPE (type), as);

and drop the build_qualified_type call for the array type itself.  Oh,
and instead of unconditionally doing that copy walk the existing
variant list to see if there is aready a properly qualified variant.

(it seems to me the apply_as_to_type function should first check
if 'type' already has the appropriate address-space qualification).

Richard.

>
> Bernd
>
>

On 09/26/2014 02:42 PM, Richard Biener wrote:
> On Fri, Sep 26, 2014 at 2:28 PM, Bernd Schmidt <bernds@codesourcery.com> wrote:
>> On 09/26/2014 02:26 PM, Richard Biener wrote:
>>>
>>> On Fri, Sep 26, 2014 at 2:14 PM, Bernd Schmidt <bernds@codesourcery.com>
>>> wrote:
>>>>
>>>> On 09/26/2014 02:05 PM, Richard Biener wrote:
>>>>>
>>>>>
>>>>> If currently address-space support matches up with the C frontend
>>>>> and the C standard then the middle-end has to cope with that.
>>>>> In this case, cope with array element types not having address-space
>>>>> qualifiers.
>>>>
>>>>
>>>>
>>>> That's the opposite of what happens. The C frontend makes array element
>>>> types have address-space qualifiers but not the array type.
>>>
>>>
>>> Ah, ok.  Then the opposite way around ;)
>>
>>
>> Ok, so that means that my original patch which updated the element types for
>> arrays is in fact the way to go?
>
> It seems to do both, apply the as to the array _and_ the element type, no?

Yes. I guess I could not do this, but then the patch will also have to 
replace all but very few uses of TYPE_ADDR_SPACE outside the C frontend 
with a new addr_space_for_type function that checks for arrays.

I can do that, but to me it feels like utterly the wrong way to go. If 
you're sure that's what you want, I'll make a patch.


Bernd

On September 26, 2014 5:14:24 PM CEST, Bernd Schmidt <bernds@codesourcery.com> wrote:
>On 09/26/2014 02:42 PM, Richard Biener wrote:
>> On Fri, Sep 26, 2014 at 2:28 PM, Bernd Schmidt
><bernds@codesourcery.com> wrote:
>>> On 09/26/2014 02:26 PM, Richard Biener wrote:
>>>>
>>>> On Fri, Sep 26, 2014 at 2:14 PM, Bernd Schmidt
><bernds@codesourcery.com>
>>>> wrote:
>>>>>
>>>>> On 09/26/2014 02:05 PM, Richard Biener wrote:
>>>>>>
>>>>>>
>>>>>> If currently address-space support matches up with the C frontend
>>>>>> and the C standard then the middle-end has to cope with that.
>>>>>> In this case, cope with array element types not having
>address-space
>>>>>> qualifiers.
>>>>>
>>>>>
>>>>>
>>>>> That's the opposite of what happens. The C frontend makes array
>element
>>>>> types have address-space qualifiers but not the array type.
>>>>
>>>>
>>>> Ah, ok.  Then the opposite way around ;)
>>>
>>>
>>> Ok, so that means that my original patch which updated the element
>types for
>>> arrays is in fact the way to go?
>>
>> It seems to do both, apply the as to the array _and_ the element
>type, no?
>
>Yes. I guess I could not do this, but then the patch will also have to 
>replace all but very few uses of TYPE_ADDR_SPACE outside the C frontend
>
>with a new addr_space_for_type function that checks for arrays.

You have the reference_addr_space function for that.

Richard.

>I can do that, but to me it feels like utterly the wrong way to go. If 
>you're sure that's what you want, I'll make a patch.
>
>
>Bernd