The stm8 port soemtimes generates this code
addw sp, #d1
addw sp, #d2
the first addw from a function call, teh second from a function return. If d1+d2 is small enough, they could be combined into one, but we would have to be able to test that in the peephole optimizer.
Another alternative might be to make code generation handle this somehow.
Philipp
How to reproduce it ?
At the end of a function that uses on-stack local variables, call a function that takes parameters. See e.g. attached example.
Philipp
Is that optimization suitable? Though the final sp's values are the same, the flags might be different. For example,
(SP = 0xfff0)
addw sp, #0x20
(SP = 0x0010, C = 1)
addw sp, #0x20
(SP = 0x0030, C = 0)
If it is simplified to "addw sp, #0x40", then
(SP = 0xfff0)
addw sp, #0x40
(SP = 0x0030, C = 1)
sdcc currently doesn't use flags for return values, so at least when the next instruction is a ret, it is safe to do.
Philipp
Take a look at stm8's user manual. "ADDW SP, #immd" does not affect flags, but "ADDW X" & "ADDW Y" do.
So is this optimization better to specialized to "ADDW SP, #immd" than generailized to "ADDW %1, #immd" (where %1 stands for x, y, and sp) ?
1) A peephole functin that lets us do basic arithmetic (addition,
subtraction) and tests the result against a range would be useful.
2) An application of this function would be a peephole rule that folds
two subsequent addw sp, #d into one.
3) There might be more applications, e.g. in instructions that load
from offsets, etc.
Philipp
I made a patch for this feature.
https://sourceforge.net/p/sdcc/patches/237/
However, there are limitations, the input immediates are only accepted in the simplest decimal form. So
addw sp, #4
addw sp, #8
addw sp, #12
can only be optimized to
addw sp, #(#4 + #8)
addw sp, #12
but not
addw sp, #(#(#4 + #8) + #12)
Should complex forms be supported ?
1. an immediate in hex and oct ?
2. an immediate in a formula ? (#x * (#y + #z))
3. the fomula immediate supports other operators (* / %) than (+ -) ?
4. an float / double immediate ?