Am 29.10.19 um 10:00 schrieb Philipp Klaus Krause:
Introducing this as a compiler extension first and also evaluate the
impact of placing register in appropriate places in some real-world code
or a benchmark would indeed make sense.
Philipp
I did a first experiment; there, the improvements in benchmarks are far
less than what one sees in synthetic examples.
Experiment:
* SDCC version based on current SDCC with support for register at file
scope added. For now, the information is used in two places in
redundancy elimination only.
* Annotated file scope variables in 4 benchmarks (Coremark, Dhrystone, stdcbench, Whetstone) with register storage class where appropriate.
* Compiled the benchmarks for STM8 with strong optimization (--max-allocs-per-node 100000), using default balanced optimization goal.
Results:
* stdcbench, Coremark: No difference at all. No surprise, since they
both use very few file scope variables, and typically not in the inner
loops.
* Whetstone: 0.8 % increase in score, 0.3 % reduction in code size.
Whtstone uses some file scope variables, but doesn't do much with
pointers, so no surprise here, either.
* Dhrystone: 1.4 % increase in score, 0.1 % increase in code size. IMO,
1.4 % is a surprisingly large increase, considering that Dhrystone tends
to spent most of its time in string functions from the standard library,
which are not affected by the change at all.
Philipp
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)