named address spaces (update)

[James E Wilson]

Martin Koegler wrote:
> I continued to work on the support for named address spaces in GCC.

This does look like a good start.

An possible issue is the effect on gcc memory usage and compile time.  I 
see you increased the size of MEM rtl which will increase memory usage. 
  Also, there seem to be a lot of hooks in commonly called functions 
which may slow down gcc.  Most users won't be happy if gcc gets slower 
in order to implement an obscure feature that most don't need.  It would 
be useful to measure the effect on compile time performance, and try to 
reduce it if it is too much.

It would be helpful if you used -p when running diff.  That includes 
function names in the output, which makes the patch easier to read. 
Also, a ChangeLog entry would help.

In previous threads, Joseph Myers pointed you at a formal proposal to 
extend the ISO C language with a similar feature.  Have you looked at 
this?  If we are adding this feature, it would be best if we followed 
the standard, instead of inventing our own incompatible extensions.

I see lots of places where you haven't followed the GNU coding 
conventions.  This will matter if you are serious about getting this 
patch into the FSF tree.  Comments need to start with a capital letter 
and end with a period.  Functions must have a comment before them that 
explains what they do, and what their arguments are.  Spaces before open 
parentheses.  Spaces before and after operators like = and !=.

namespace means something different in C++.  I don't think it is wise to 
reuse it here.  addressspace or addrspace makes more sense.

It isn't clear why you want both decl and type attributes.  If we are 
doing this right, it seems that it should just be a type attribute (type 
qualifier?), and then for decls you can get the info from their type.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com