SDCC : mcs51/z80/z180/r2k/r2ka/r3ka/sm83/tlcs90/ez80_z80/z80n/r800/ds390/pic16/pic14/TININative/ds400/hc08/s08/stm8/pdk13/pdk14/pdk15/mos6502 TD- 4.3.2 #0 (Linux)
published under GNU General Public License (GPL)
command line:
sdcc -c -DTEST8051 -pmcs51 aa.c -I"$SDCC_HOME/include/mcs51/"
generated assembly:
; aa.c:8: if(k<0)
mov r7,a
jnb acc.7,00102$
; aa.c:11: k++;
inc r4
cjne r4,#0x00,00114$
inc r5
cjne r5,#0x00,00114$
inc r6
cjne r6,#0x00,00114$
inc r7
however, aa.c line 10 is
k=~k;
disappeared.
I dumped the I-CODE and find the miss is in the "LRANGE" optimization.
Any help will be appreciated.
Chingson
Discussion: Need help about https://sourceforge.net/p/sdcc/bugs/3642/
Wiki: SDCC 4.4.0 Release
I see the problem in current trunk when compiling for mcs51 or ds390. On the other hand, I do not see the problem when compiling for z80, hc08, pdk15 or stm8.
sdcc/src/SDCCopt.c line 3309:
if (optimize.lospre && (TARGET_Z80_LIKE || TARGET_HC08_LIKE || TARGET_IS_STM8)) /* For mcs51, we get a code size regression with lospre enabled, since the backend can't deal well with the added temporaries */
If add back the optimization in this line for mcs51, the bug will be disappeared.
I don't know why pdk15 has not that problem.
I just don't understand the corresponding optimization procedure. Is there any more documents for the optimizations?
Last edit: Maarten Brock 2023-09-12
lospre is a redundancy elimination technique: https://dl.acm.org/doi/10.1145/3493229.3493304
For this bug, that most likely doesn't matter though. I guess it just makes some change to the iCode, which then happens to result in the real bug not being triggered for this example later in SDCC.
P.S.: For me, looking at the iCode dumps, dumpgenconstprop is the last one that still has the complement, but it is gone in dumprange (apparently around the time the complement is lost, iTemp0 is replaced by iTemp9).
P.P.S.: The bug apparently gets introduced in live-range separation. Dumping the code just after live-range separation shows:
I think that the problem is that in iCode 10 both iTemp0 got replaced by the new iTemp9, while only the result operand should have been replaced.
Last edit: Philipp Klaus Krause 2023-10-26
In [r14390] I added a regression test for this bug (disabled for now, until the bug is fixed).
Related
Commit: [r14390]
Fixed in [r14406].
Related
Commit: [r14406]