As per the subject, I was wondering if it was worth to open a new feature request for a new (potential) optimizer rule.
If it's not the case, here's the point: isn't it the assignment in register E completely avoidable loading directly to register L the value in (HL) and incrementing that?
done compiling with -mz80, with SDCC version as follows:
SDCC : mcs51/z80/z180/r2k/r3ka/gbz80/tlcs90/ds390/pic16/pic14/TININative/ds400/h
c08/s08/stm8 3.6.0 #9615 (MINGW32)
published under GNU General Public License (GPL)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If it's not the case, here's the point: isn't it the assignment in register E completely avoidable loading directly to register L the value in (HL) and incrementing that?
Yes but you're tugging at the end of a long rope. Currently I have about a thousand peephole rules that fix up sdcc's generated code -- the list becomes long very quickly :)
sdcc's z80 peepholer is currently bugged such that it cannot always determine when registers are read or written by individual instructions. This prevents it from applying the peephole rules in many circumstances. This is barely noticeable on native sdcc because its peephole set is fairly small but when you have a lot of rules that feed each other, the failure to apply them becomes obvious.
The patch to fix this is available somewhere on here but the combination of it being, admittedly, a little hackish and the devs not being able to see much difference in sdcc testing due to sdcc's small peephole set, has conspired to make it low priority / forgotten. At some point I will revisit it and submit a better patch if someone else doesn't get around to it. (It is patched in z88dk where the expanded rules give quite large savings in typical output binaries).
Last edit: alvin 2016-11-02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You might post to the mailing list or here first, and see if the situation improves. When a developer is currently working in that area it will often happen.
But if, like here nothing like that happens for a while it is better to file a feature request, so it won't be forgotten.
Philipp
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As per the subject, I was wondering if it was worth to open a new feature request for a new (potential) optimizer rule.
If it's not the case, here's the point: isn't it the assignment in register E completely avoidable loading directly to register L the value in (HL) and incrementing that?
done compiling with -mz80, with SDCC version as follows:
Yes but you're tugging at the end of a long rope. Currently I have about a thousand peephole rules that fix up sdcc's generated code -- the list becomes long very quickly :)
sdcc's z80 peepholer is currently bugged such that it cannot always determine when registers are read or written by individual instructions. This prevents it from applying the peephole rules in many circumstances. This is barely noticeable on native sdcc because its peephole set is fairly small but when you have a lot of rules that feed each other, the failure to apply them becomes obvious.
The patch to fix this is available somewhere on here but the combination of it being, admittedly, a little hackish and the devs not being able to see much difference in sdcc testing due to sdcc's small peephole set, has conspired to make it low priority / forgotten. At some point I will revisit it and submit a better patch if someone else doesn't get around to it. (It is patched in z88dk where the expanded rules give quite large savings in typical output binaries).
Last edit: alvin 2016-11-02
You might post to the mailing list or here first, and see if the situation improves. When a developer is currently working in that area it will often happen.
But if, like here nothing like that happens for a while it is better to file a feature request, so it won't be forgotten.
Philipp