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

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

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