> Giovanni Bajo writes: >> Dale Johannesen <[EMAIL PROTECTED]> wrote: >>> I do think the C++ FE needs fixing before Diego's change gets merged, >>> though. I can make the change, but not instantly. If someone files >>> a PR, and assigns to me, I'll get to it at some not-too-distant >>> point. >> >> It would be good to have a way to mark things as "write once, then >> readonly" IMO. It's very common, and you can do some of the same >> optimizations on such things that you can do on true Readonly objects. > > We had this once, it was called RTX_UNCHANGING_P, and it was a big mess. > Progressively, we have been removing TREE_READONLY from C++ const variables > (which are "write once" from the GCC IL point of view), and this is another > instance of the same problem. > > We probably need a better way to describe C++ constructors, maybe something > like WRITEONCE_EXPR which is a MODIFY_EXPR with a READONLY on its lhs, and > which is supposed by the frontends when initialing such variables.
GCC's present consistent use of the readonly attribute to tag references to declared or compiler generated read-only "static const data" (as may be used to initialize runtime allocated constants or variables if not in-lined as immediate data by the compiler) should be preserved; as such references seem to be uniquely the only true read-only memory references static data which may be potentially more optimally allocated and accessed as desired. (therefore non static data references should not be marked read-only) Correspondingly, the use of MEM_READONLY_P seems to be the only convenient method available to enable identification of such references to enable the generation of target specific instructions as may be required if static data is directly mapped-to and accessed-from the target's ROM, in lieu of requiring all "static data" be potentially redundantly copied into the target's RAM prior to use, which may be impractical or even simply impossible for targets which have very limited available RAM. This approach basically works today, less a few bugs such as a static data pointer's attributes not being consistently copied to the BLK mode pointer for block memory moves; and the present inability to define a function parameter which may point to static storage qualified type, although having a normal or register storage type itself (which seems to be allowed by the standard), as opposed to specifying the parameter as having a storage type other than register itself (which is prohibited by the standard), thereby enabling the consistent specification of differentiable "(static const) *" and "(const) *" qualified pointer parameters. both per: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20937
