On Wed, May 2, 2012 at 8:08 AM, Paulo J. Matos <pa...@matos-sorge.com> wrote: > On 30/04/12 13:01, Peter Bigot wrote: >> >> I would like to see the technical details, if your code is released >> somewhere. >> > > Hi Peter, > > Sorry for the delay. > The code is not released, however I can send you a patch against GCC 4.6.3 > sources (our GCC 4.7.0 port is not yet stable) of our changes and will also > try to explain how it works.
Thanks; I'd appreciate it. >> Without having started it yet, I'm thinking this can be done by >> modifying build_pointer_type to generalize the >> TARGET_ADDR_SPACE_POINTER_MODE to TARGET_TYPE_POINTER_MODE, pass it >> the whole type instead of just the address space field, and moving >> TARGET_ADDR_SPACE_POINTER_MODE support to the default implementation >> for that hook. Likewise for build_reference_type. Then judicious >> application of attributes to types and decls would allow detection of >> the situation where a non-standard pointer size is needed. I'm hoping >> there aren't too many other places where that work would get undone. >> I've had pretty good success with the above approach, involving the following changes: * Eliminate some gratuitous passing of function expressions through memory_address(), which insists on treating everything as though it was in ADDR_SPACE_GENERIC and therefore forces a conversion to Pmode; also fix one use of Pmode which probably should have been FUNCTION_MODE back when it was added by rms in 1992. * Provide new TARGET_TYPE_* hooks paralleling TARGET_ADDR_SPACE_* so that the appropriate pointer and address modes can examine the whole type tree, rather than assuming the address space is sufficient. This provides access to attributes that influence the selection of appropriate mode, which I need for both data and function types. * Cache the desired pointer_mode and address_mode values in struct mem_attrs instead of assuming addrspace is sufficient to recalculate them. All in all, not too painful. These'll be in the mspgcc git repository for gcc at http://mspgcc.git.sourceforge.net/git/gitweb.cgi?p=mspgcc/gcc;a=summary in a couple weeks when I do another release. Dunno whether it's worth considering them for trunk sometime. > As you will see, I haven't used anything related to address spaces feature > in GCC. Yeah, the fact that address spaces are ignored for function types, and apparently aren't available in C++, makes them useless for my needs even though the support infrastructure is very similar to what I wanted. Peter
