>> 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.)
