Fw: Possible missed optimization opportunity with const?

David Brown david@westcontrol.com
Thu Sep 1 19:33:00 GMT 2016


On 01/09/16 21:11, Toshi Morita wrote:
>
>
> 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.

In cases like that, you can do your caching manually.  Just read the rom 
value once, and keep the value in a local variable - then it will stay 
in a local register.  If you have a lot to read and re-use, copy a block 
to SRAM.  This is something that the compiler could never do on its own 
- you have to write it in the code.

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

This was already explained to you by Florian - the compiler cannot make 
the optimisation you want, because it does not know that the object at 
address 0x1234 is truly constant.  The "const" in the pointer here can 
only tell the compiler that /you/ will not try to change its value. 
This is different from the case where you define pfoo from the address 
of foo, because you have defined foo to be constant - now the compiler 
knows it cannot change, and can optimise accordingly.

To be able to get the kind of optimisation you are asking for, you would 
need to be able to tell the compiler that the thing pfoo points to is 
really constant - that would need a new __attribute__ or similar 
extension.  Alternatively, you would need a new __attribute__ to let you 
declare a const foo at a specific address (this might be easier, since 
the relevant __attribute__ already exists for avr-gcc).




More information about the Gcc-help mailing list