[Z80] Test results for SDCC 4.6

[Aoineko]

Hello,

As I haven’t encountered any issues so far (I’ve only just started testing SDCC 4.6 RC1), I’m creating this thread to share my findings.

To begin with, I focused on the size of generated programs using MSXgl C library.

I compared:

• SDCC 4.2 (the reference version for the library)
• SDCC 4.5
• SDCC 4.6 RC1

The tests were carried out using the default compilation options and without allowing the use of undocumented Z80 instructions (to ensure a consistent basis for comparison with SDCC 4.2).

Here are the size differences (in bytes) between SDCC 4.2 and 4.6:

Program                         4.2     4.5     4.6 RC1     Diff
------------------------------------------------------------------------
Chrono Runner (game)            98455   98154   98117       -338
Crawlers (game)                 48904   48877   48684       -220
Final Smash (game)              46734   46064   46146       -588
Gods of Soccer (poc)            26857   26028   25859       -998
JSX (tool)                      34896   33207   33243       -1653
Movie (demo)                    6541    6476    6469        -72
NY2024 (demo)                   30637   30491   30416       -221
NY2025 (demo)                   20973   21220   20784       -189
NY2026 (demo)                   35474   35297   35339       -135
Phenix-Corrupta (game)          401124  396775  395840      -5284
Pisa (demo)                     23758   22832   22713       -1045
pongoid (game)                  8111    7938    7963        -148
Room 5 (game)                   44429   44022   43936       -493
samprexp (game)                 110592  109378  108995      -1597
Spirit Cards (poc)              98515   99305   99011       +496 /!\
The Castel (game)               31515   32732   32453       +938 /!\
Trapped (game)                  130685  129573  129664      -1021
VATT (tool)                     28987   28706   28516       -471

There are two specific cases (which I will look into further), but overall, the generated code is smaller than that of version 4.2, and in some cases by a significant margin.
Compared to version 4.5, there are instances where version 4.6 performs less well, but overall, it seems to be an improvement.

Obviously, size isn’t the only indicator of the quality of the generated code… but it’s the easiest to test.

Now I’m going to run some functional tests to make sure all the test programmes work properly with version 4.6, and then I’ll test the performance.

Everything's fine for now.
Thanks to the SDCC team!

[Aoineko]

I was able to investigate the issues I had found with 4.6.0 RC2:

• The crash in one of the test projects was not caused by SDCC 4.6 (the program only worked under specific timing conditions 🤦)
• The significative increase in the size of two projects appears to be due to 16-bit calculations that used to go through the HL/DE registers with SDCC 4.2 and now involve numerous accesses via the IX register. Not only does this increase the program's size, but it also slows it down significantly.

I have three .ASM files in versions 4.2 and 4.6 RC2 to compare.
The programs are compiled with the default options.

Here is an example with an inline function that is much better optimized with SDCC 4.2 than with 4.6 RC.

SDCC 4.2

;C:/dev/MSX/MSXgl/engine/src/vdp.h:1392: inline void VDP_Poke_GM2(u8 x, u8 y, u8 value) { VDP_Poke(value, g_ScreenLayoutLow + (y * 32) + x, g_ScreenLayoutHigh); }
    ld  l, b
    ld  h, #0x00
    add hl, hl
    add hl, hl
    add hl, hl
    add hl, hl
    add hl, hl
    ld  de, (_g_ScreenLayoutLow)
    add hl, de
    ld  e, -2 (ix)
    ld  d, #0x00
    add hl, de
    ex  de, hl
    ld  a, -3 (ix)
    call    _VDP_Poke_16K

SDCC 4.6 RC2

;C:\dev\MSX\MSXgl\engine/src/vdp.h:1392: inline void VDP_Poke_GM2(u8 x, u8 y, u8 value) { VDP_Poke(value, g_ScreenLayoutLow + (y * 32) + x, g_ScreenLayoutHigh); }
    ld  a, -4 (ix)
    ld  -5 (ix), a
    ld  -4 (ix), #0x00
    ld  b, #0x05
00280$:
    sla -5 (ix)
    rl  -4 (ix)
    djnz    00280$
    ld  hl, (_g_ScreenLayoutLow)
    ld  -9 (ix), l
    ld  -8 (ix), h
    ld  a, -5 (ix)
    ld  -7 (ix), a
    ld  a, -4 (ix)
    ld  -6 (ix), a
    ld  e, -7 (ix)
    ld  d, -6 (ix)
    ld  l, -9 (ix)
    ld  h, -8 (ix)
    add hl, de
    ld  -5 (ix), l
    ld  -4 (ix), h
    ld  a, -10 (ix)
    ld  -7 (ix), a
    ld  -6 (ix), #0x00
    ld  e, -7 (ix)
    ld  d, #0x00
    ld  l, -5 (ix)
    ld  h, -4 (ix)
    add hl, de
    ld  -9 (ix), l
    ld  -8 (ix), h
    ld  a, -9 (ix)
    ld  -5 (ix), a
    ld  a, -8 (ix)
    ld  -4 (ix), a
    ld  e, -5 (ix)
    ld  d, -4 (ix)
    ld  a, -3 (ix)
    call    _VDP_Poke_16K

Is this a known issue?

[Philipp Klaus Krause]

Which command-line options did you use? Did you use --max-allocs-per-node? If yes, with which argument? Have you also tried compiling these with a higher argument for --max-allocs-per-node (not specifying it at all is equivalent to --max-allocs-per-node 3000)?

[Aoineko]

I'm always using default option when comparing SDCC versions.

I tried several complexity values, and you can indeed see that while SDCC 4.6 doesn't perform very well on the TheCastle project with the default settings compared to version 4.2, its performance gradually improves as the complexity increases (where version 4.2 doesn't seem to converge).

4.2         4.6 RC2     Compile options
----------------------------------------------------------------------
31 515      32 482      default
31 458      31 934      --opt-code-speed --max-allocs-per-node 5000
31 154      30 578      --opt-code-speed --max-allocs-per-node 50000
31 567      30 166      --opt-code-speed --max-allocs-per-node 500000

[Philipp Klaus Krause]

I'm glad no serious (i.e. generation of wrong code)issues came up. The code size regression looks like it might be due to the register allocator making worse choices in your case, which in turn might be the result of it having more freedom now than in SDCC 4.2.0. The register allocator is guided by some hard rules, but also heuristics when it can't prove what is best. Those heuristics are sometimes changed a bit, but none can be perfect for all code. In general, only a higher --max-allocs-per-node argument can help (but comes at the cost of longer compile times and higher memory use during compilation).