> James E Wilson wrote: > ... > It relies on MEM_EXPR always being set, which may not be true. But if > there are places creating MEMs from decls without setting MEM_EXPR, then > they probably should be fixed. MEMs created for things like spills to stack > slots may not have MEM_EXPR set, but then they can't possibly have the > eeprom attribute either, so that is OK. > > This could be a maintenance problem if other developers make changes and > forget to keep the MEM_EXPR fields accurate. The more we use the MEM_EXPR > fields, the less of a problem this will be.
- Might it be possible to introduce and use by convention a new macro which will always wrap a new pointer in a mem expression with attributes copied from the previous mem/symbol's reference enforced? (Thereby hopefully making it more convenient and less error prone? Ideally possibly supporting at least a few generic target definable attributes which are correspondingly preserved for all variable, literal-data, and function result and parameter object declaration references by default.) > ... > Presumably this is only a problem because some MEMs don't have the > MEM_EXPR field set, in which case a better solution is to find the places > that forget to set it and fix them. - One of the things that's been eluding me, is that I can't seem to find where literal string constant mem references aren't being properly declared and/or preserved as READONLY/unchanging references, resulting in MEM_READONLY_P failing to identify them; although literal char array references, which seem logically equivalent, do seem to be properly declared/preserved? Any insight would be appreciated, -paul-
