Re: Q: C++ FE emitting assignments to global read-only symbols?

[Paul Schlie <schlie at comcast dot net>]

> Giovanni Bajo writes:
>> Dale Johannesen <dalej@apple.com> 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