This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Q: C++ FE emitting assignments to global read-only symbols?
- From: Paul Schlie <schlie at comcast dot net>
- To: Daniel Berlin <dberlin at dberlin dot org>
- Cc: <gcc at gcc dot gnu dot org>,Dale Johannesen <dalej at apple dot com>,Diego Novillo <dnovillo at redhat dot com>,Mark Mitchell <mark at codesourcery dot com>
- Date: Sat, 09 Apr 2005 00:19:16 -0400
- Subject: Re: Q: C++ FE emitting assignments to global read-only symbols?
>> On Fri, 2005-04-08 at 16:51 -0700, Dale Johannesen wrote:
>>> On Apr 8, 2005, at 4:40 PM, Mark Mitchell wrote:
>>>> Daniel Berlin wrote:
>>>> Your transform is correct.
>>>> The FE is not. The variable is not read only.
>>>> It is write once, then read-only.
>>>
>>> Diego, your analysis is exactly correct about what is happenning.
>>>
>>> I agree, in principle. The C++ FE should not set TREE_READONLY on
>>> variables that require dynanmic initialization. Until now, that's not
>>> been a problem, and it does result in better code. But, it's now
>>> becoming a problem, and we have others way to get good code coming
>>> down the pipe.
>>>
>>> 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.
>
> Some of these global properties probably belong in cgraph_var node's
> instead of shoving them into the tree structure.
> Especially if they are only going to be checked a few times (I can't
> imagine an optimization would ask the same variable if it is write-once
> more than once or twice)
Would it then still be possible for a target to identify all accesses to
"read-only" constant or initializing string/array/structure values which
may be designated to be literally stored in a read-only memory, vs being
in-lined as immediate values in the code, so that specialized instruction
sequences which may be generated to access these values if required by the
target?
(i.e. were "read-only" constant values are truly literally stored in
a dedicated ROM memory space, and accessed directly as required; vs.
initializing RAM based constants upon program startup.)