On Tue, Sep 16, 2014 at 1:24 PM, Bernd Schmidt <ber...@codesourcery.com> wrote: > On 09/12/2014 01:48 PM, Richard Biener wrote: >> >> On Fri, Sep 12, 2014 at 1:15 PM, Bernd Schmidt <ber...@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 > >
