#3642 Missed complement operation after lrange optimization

[Chingson Chen]

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

[Philipp Klaus Krause]

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.

[Chingson Chen]

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?

[Philipp Klaus Krause]

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:

aa.c(l10:s6:k7:d0:s0:b3)        iTemp0 [k2 lr3:15 so:0]{ ia0 a2p0 re1 rm0 nos0 ru0 dp0}{long-int fixed}{ sir@ _ss_k_65536_1} = ~ iTemp9 [k15 lr0:0 so:0]{ ia0 a2p0 re0 rm0 nos0 ru0 dp0}{long-int fixed}
aa.c(l11:s7:k10:d0:s0:b3)       iTemp9 [k15 lr0:0 so:0]{ ia0 a2p0 re0 rm0 nos0 ru0 dp0}{long-int fixed} = iTemp9 [k15 lr0:0 so:0]{ ia0 a2p0 re0 rm0 nos0 ru0 dp0}{long-int fixed} + 0x1 {const-unsigned-char literal}

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.

[Philipp Klaus Krause]

In [r14390] I added a regression test for this bug (disabled for now, until the bug is fixed).

[Philipp Klaus Krause]

Fixed in [r14406].