#803 optimization: XOR with 0 suppress

[Konstantin Kim]

I found some difference in code generation between padauk and msc51 targets.

unsigned long long  foo=1;
void main() {
    for(;;) foo ^= 0xFFFFFF55;
}

for pdk14 sdcc emit perfect code

00102$:
    mov a, #0x55
    xor _foo+0, a
    not _foo+1
    not _foo+2
    not _foo+3
    goto    00102$

but for mcs51 it looks a bit ugly

00102$:
    xrl _foo,#0x55
    xrl (_foo + 1),#0xff
    xrl (_foo + 2),#0xff
    xrl (_foo + 3),#0xff
    xrl (_foo + 4),#0x00
    xrl (_foo + 5),#0x00
    xrl (_foo + 6),#0x00
    xrl (_foo + 7),#0x00
    sjmp    00102$

I believe that it might be better to eliminate useless XORs in genXor rather by peephole rule as it made in PDK case.

[Deqing Sun]

Yes I got similar issue
[#748]

                                    641 ;   ch552_test_16bit_optimization.ino:7: volatile uint8_t a=1;
      000007 75*00 01         [24]  642     mov _setup_a_65536_146,#0x01
                                    643 ;   ch552_test_16bit_optimization.ino:8: volatile uint16_t d=(1<<8)|a;
      00000A AE*00            [24]  644     mov r6,_setup_a_65536_146
      00000C 7F 00            [12]  645     mov r7,#0x00
      00000E 43 07 01         [24]  646     orl ar7,#0x01
      000011 8E*01            [24]  647     mov _setup_d_65536_146,r6
      000013 8F*02            [24]  648     mov (_setup_d_65536_146 + 1),r7

[Deqing Sun]

Similar optimization is also needed to add.

volatile uint8_t a = 1;
volatile uint16_t d; 
d = (1<<8)+a;
      00002D AE*02            [24]  691     mov r6,_setup_a_65536_148
      00002F 7F 00            [12]  692     mov r7,#0x00
      000031 74 01            [12]  693     mov a,#0x01
      000033 2F               [12]  694     add a,r7
      000034 FF               [12]  695     mov r7,a
      000035 8E*04            [24]  696     mov _setup_d_65536_148,r6
      000037 8F*05            [24]  697     mov (_setup_d_65536_148 + 1),r7

[Maarten Brock]

The problem is not in the addition here. First a needs an upcast which assigns the zero to r7. Then it is added to (1<<8).
This is probably really handled best by a peephole rule. Register tracking may be used to find the value of r7 instead of relying on the position of the assignment. But care must also be taken not to corrupt the carry after the removal of add.

[Konstantin Kim]

I'm afraid that's off topic. You may not expect optimizations with "volatile"

[Gabriele Gorla]

I cannot reproduce the issue with either SDCC 4.2.0 or trunk

00102$:
;   xor.c:5: for(;;) foo ^= 0xFFFFFF55;
    xrl _foo,#0x55
    xrl (_foo + 1),#0xff
    xrl (_foo + 2),#0xff
    xrl (_foo + 3),#0xff
;   xor.c:6: }
    sjmp    00102$

sdcc -v
SDCC : mcs51/z80/z180/r2k/r2ka/r3ka/sm83/tlcs90/ez80_z80/z80n/ds390/TININative/ds400/hc08/s08/stm8/pdk13/pdk14/pdk15/mos6502 4.2.0 #13081 (Linux)
published under GNU General Public License (GPL)

[Konstantin Kim]

It's there up to 4.3.1_20231106-14398, including 13081.
From 4.4.0_20231222-14549, the topic is no longer relevant.
Could possibly narrow it down, but this is what I can verify quickly.

[Philipp Klaus Krause]

The generated asm looks fine in current trunk.