#3716 8051 ACC/A minor regression

[Konstantin Kim]

By compiling project https://github.com/diodep/ch55x_jtag
I found funny minor deoptimization.
Two byte instruction with ACC used instead of single-byte one with A.

4.4.1 #14710 (MINGW64):

                               3162 ;   main.c:1375: Modem_Count --;
  000B93 78r18            [12] 3163     mov r0,#_Modem_Count
  000B95 86 E0            [24] 3164     mov acc,@r0
  000B97 78r18            [12] 3165     mov r0,#_Modem_Count
  000B99 14               [12] 3166     dec a
  000B9A F6               [12] 3167     mov @r0,a
  000B9B                       3168 00102$:

4.1.14 #12912 (MINGW64):

                               3209 ;   main.c:1375: Modem_Count --;
  000BCF 78r18            [12] 3210     mov r0,#_Modem_Count
  000BD1 E6               [12] 3211     mov a,@r0
  000BD2 78r18            [12] 3212     mov r0,#_Modem_Count
  000BD4 14               [12] 3213     dec a
  000BD5 F6               [12] 3214     mov @r0,a
  000BD6                       3215 00102$:

[Maarten Brock]

This looks like a missed peephole optimization. Can you generate it again with --fverbose-asm so we can see which peephole rules were (not) applied?

[Konstantin Kim]

I have analyzed the assembly code generated with the '--fverbose-asm' option, and it shows that the peephole rules were applied exactly the same in both cases. There is no differences.

The only difference I observed is the use of the ACC instead of the A in the given context.
A difference was introduced somewhere between the following two versions:
SDCC_4.3.1_20231106-14398
SDCC_4.4.0_20231222-14549

[Konstantin Kim]

Another concern that needs to be addressed is the absence of R0 value tracking.

[Konstantin Kim]

The trigger of this situation is the simultaneous use of "volatile" "__idata"

volatile __idata uint8_t cnt;
void test(void) {
    if(cnt) cnt--;
}