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