On Fri, Jul 01, 2005 at 06:49:18PM -0700, James E Wilson wrote: > Martin Koegler wrote: > >I continued to work on the support for named address spaces in GCC. > > 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.
Named address spaces will need some bits to store information about them in the RTL as well as in the tree nodes. I could change the patch, that it only creates code on target, which support it. But I do not like this idea, because future enhancements (like support for different sized pointers) will probably require bigger changes in the core, which will get more difficult, if only some architectures use it. If have not done any benchmarks yet, as I am working on improving my m68hc05 GCC port. I ran the GCC testsuite (only for the C frontend) with my patches on the i386 frontend and it took about 45 minutes complete on a modern P4 system (I have not collected more information, so it says nothing). > 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. The next time, I send an update, I will try to produced a better readable patch. > 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 !=. I have not cared about any formating conventions yet, as it is a preview patch (and the mentioned errors are no technical problem). Merging this patch will need a backend, which supports it. I do not intend to try to include my m68hc05 port in the GCC mainline, as I know no (potential) user base for this port (except my BCU SDK). So this patch will need an other backend, problably avr, over which it will find its way in the GCC CVS. > namespace means something different in C++. I don't think it is wise to > reuse it here. addressspace or addrspace makes more sense. In my working tree, I switch to addrspace: ADDRSPACE (EEPROM, HI); I also added an information about the minimum pointer size to start to work on non Pmode pointer. > 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. Yes, I took it as base for the semantics (e.g. showed the need for the addrspace merge functions). I have not changed the C frontend to support address space attributes, so the specified syntax is not implemented. Instead I currently use GCC attributes. The attribute handlers in my backend only set the address space, without allocation variables into a specific section or detecting errors (eg. parameters with EERPOM attribute). > 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. My first implementation used a GCC type attribute to store the address space of the current value. I had serveral problems: * DWARF2 errors on arrays (#21106) * need to rewrite recursivly each element of type (which my contain structures, unions, ...) if a address space is set In http://gcc.gnu.org/ml/gcc/2005-04/msg01438.html, this was rated as bad idea. If the address space is set, it would be possible, that only the the address space is only stored in the top level node and every code, which access a part of the type, would duplicate the subtree and store the correct address space in the new top. This would require bigger changes, than the current solution. Now, I do not store the address space of variables in the type to avoid all propagation problems, I had in former implementations. Only for pointers, I store the address space, the pointer points to, in the type. I do the propagation while creating the different tree expression now (by storing the address space of the result in the expression). Using this approach, it is not possible to create something like typedef int eint __attribute__ (eeprom);, where eint x; will allocate x in the eeprom. On the other hand, situations, where eint is used in a structure (in the normal address space), can not happen. The ISO document does not explicitly state, if such constructs are allowed or not, so I can't say, if the ISO C extension support this. As I store the address space in the DECL, this can be best changed by a DECL attribute. For pointer (and references), I need a way to specifiy the address space of the target. Here a type attribute is the only solution, as they may be used in a structure. mfg Martin Kögler
