Fw: Possible missed optimization opportunity with const?

[Toshi Morita]

David Brown wrote:
>> Another example is mask-programmed ROM or EPROM. These devices are
>> usually fairly slow with access times ranging from 125 ns to 450 ns.
>> Since these devicesare so slow, it is preferable to avoid unnecessary
>> reads to the device. The values in a mask-programmed ROM cannot be
>> changed, and the values in an EPROM can only be changed when the
>> device is powered off and exposed to UV light for several minutes, so
>> the values are effectively const and do not change at runtime.

> Usually you can treat such data as const, that's true.  But again, I am 
> having a hard time understanding why it might matter if you read the 
> data twice (it's not /that/ slow - especially in comparison to calling a 
> function in between reads), and why you can't simply store the first 
> read in a local variable in cases where it /does/ matter.  And in 
> microcontrollers that are fast enough for this to matter, you've 

> probably got a cache that can be used.

I've worked on one platform with a dual ARM7 running at 100 Mhz and no cache.
ROMs had a cycle time of 450 ns, and the processor has a cycle time of 10 ns.
So it's 45 clock cycles to access ROM.
> I'm all in favour of better optimisations, but this looks like a lot of 

> effort (for either the gcc developers, or for the programmer) for a
> negligible gain.

If you look at my original message, you will see that this optimization is
already implemented and works for the case where pfoo = &foo.

It fails when foo is replaced with a (const int * const) address.

I suspect when the C front-end parses (const int * const)0x1234, it fails
to apply the const_tree attribute to the subtree, and this is why the
optimization is failing.

Toshi