Fw: Possible missed optimization opportunity with const?
Thu Sep 1 20:50:00 GMT 2016
> 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.
Yes, this is obvious, but in some cases this is not feasible, such as porting
a large codebase to a new platform with time constraints and/or porting
code where the license prohibits changing the code.
> 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.
> 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).
The --defsyms approach seems easier.
More information about the Gcc-help