Performance regression in April 2026 release for 8086 DOS target

[ggeorgovassilis]

Performance Regression: Less optimal register allocation and branch inversion on 8086 (-ox -ok)

Description

With the Open Watcom Beta release (April 2026), testing an 8086 C++ code base targeting DOS revealed a performance regression compared to the March 2026 release. Through disassembly diffing, I traced the regression strictly to how the clampi logic (a small inline function) was lowered to assembly inside a complex translation unit (for reference: Object3D::addDirtyRect), when compiled with maximal optimisations -bt=dos -0 -ml -wx -oa -oe -oh -oi+ -ok -ol -os -ox -oz -s -zm -zq. This issue is specific to the space-optimisation flag -os.

Detailed Observation

The regression takes the form of replacing fast arithmetic (e.g. dec accompanied by optimal register-to-register moves) with lea effective-address instructions, shifting which register holds values in branches, and generating flipped jg/jle condition blocks that result in slightly worse throughput on an actual 8086 processor.

C++ Source extract:

static inline int clampi(int v, int lo, int hi) {
    if (v < lo) return lo;
    if (v > hi) return hi;
    return v;
}

void Object3D::addDirtyRect(const RenderContext &ctx, short minX, short minY,
                            short maxX, short maxY) {
    const short w = (short)ctx.screenW;
    const short h = (short)ctx.screenH;
    
    if (maxX < 0 || minX >= w || maxY < 0 || minY >= h) return;

    minX = clampi(minX, 0, w - 1);
    minY = clampi(minY, 0, h - 1);
    maxX = clampi(maxX, 0, w - 1);
    maxY = clampi(maxY, 0, h - 1);
    // ...
}

March Release Generated Code (Good)

        mov             dx,ax
        dec             dx                   ; dx = w - 1 (2 clocks)
        test            bx,bx
        jge             L$54
        xor             bx,bx
        jmp             L$55
L$54:
        cmp             bx,dx
        jle             L$55
        mov             bx,dx
L$55:

April Release Generated Code (Regressed)

        lea             ax,-1[di]            ; ax = w - 1 (slower LEA on 8086)
        test            bx,bx
        jge             L$54
        xor             ax,ax
        jmp             L$55
L$54:
        cmp             bx,ax
        jg              L$55
        mov             ax,bx
L$55:

Additionally, more values spill from registers requiring reload across similar clamping calls further down.

Steps to Reproduce

Unfortunately, the codebase which exhibits this behaviour is complex and I wasn't able to extract a reliable test case. Because global register flow optimisations (-ok, -ox) are stateful with respect to the translation unit, extracting just the clampi function into a trivial test.cpp causes the compiler to magically perfectly allocate registers due to the lack of surrounding register pressure.

Expected Behaviour

The new release should ideally preserve the optimal instruction selection/register mapping of the March compile, avoiding slower lea instructions compared to simple register arithmetic (dec).

Closing notes

Please note that the compiler "traditionally" produces faster code with -os than -ot for the 8086, which is the motivation behind this report. I casually observed that the April release produces faster output for -ot than the March release, though for both March and April -os is faster than -ot, so if speed is an objective, the April release is for my code base a regression as there is no workaround.

[jmalak]

Thanks you for your report.
I will check appropriate code and how it is selected, may be incorrectly handled dependency on size/speed options.

Please did you check with OW 1.9 compiler?

I checked all changes in code generator and front end and there is not changes related to registers allocation or optimization code, generaly to any significant code.
Please could you add fully compilable sample code because it is inline code and can depend on full compilation unit optimization.

[ggeorgovassilis]

Thank you for the response.

Please did you check with OW 1.9 compiler?

I did not. I should have noted that I'm using the linux compiler; 1.9 doesn't seem to have that.

Please could you add fully compilable sample code

Currently the code is closed-source and I can't publish it yet. With your permission, I'd invite you as a collaborator?

[jmalak]

It cannot be big example only some class which use this construct and show this issue.
I need also compile command line to be able reproduce your issue.

[ggeorgovassilis]

It cannot be big example only some class which use this construct and show this issue.

Like I wrote earlier, I wasn't able to do that. Any subset extraction that I attempted which both compiles and runs doesn't exhibit this behaviour.

and there is not changes related to registers allocation

May I please turn your attention to this commit: 0e499a2

This changes how sorting works in regalloc.c::SortConflicts. The sorting algorithm used there isn't stable; equal things don't sort out the same way. If that is correct, the commit referenced earlier probably introduced more regressions.

[ggeorgovassilis]

This changes how sorting works in regalloc.c::SortConflicts. The sorting algorithm used there isn't stable; equal things don't sort out the same way. If that is correct, the commit referenced earlier probably introduced more regressions.

To be clear, the issue isn't the new memory allocation, but the unstable sort. There would probably be other pre-conditions that change the outcome.

[jmalak]

I don't agree with you, the sort algorithm was not changed anyway, it is still original one from original WATCOM code.
The SortList function is used for all sorting, if there is problem the code generator will be unusable.
It looks more like a memory problem and due to code change affected memory change too.

[ggeorgovassilis]

the sort algorithm was not changed anyway

Then the issue pre-existed?

if there is problem the code generator will be unusable

As far as I can tell, the unstable sorting causes a change in register allocation and emitted instructions, which leads to different code, but otherwise functionally identical results. As nothing in the instruction generation changed between March and April, but we're still observing a change in generated instructions, it means that this stage is sensitive to an unknown condition. One such explanation is the register allocation sorting implementation which is demonstrably unstable.

[jmalak]

Sorry, it is only statement no sample code to reproduce.
If you don't include compilable sample code which exhibit your issue then we cannot help you.

[ggeorgovassilis]

Sorry, it is only statement no sample code to reproduce.

I know. I explained the reasons. You didn't respond to my invitation to review the code base, so I can't do anything about that.

then we cannot help you.

I spend a few tokens on a code review, maybe that helps? https://github.com/copilot/share/4a791188-4b84-80b0-a942-3e4b6487400e

[jmalak]

This approach is not acceptable to us, we have limited resources, so we only deal with problems that are reproducible. The output from the copilot is definitely not evidence.

[ggeorgovassilis]

we have limited resources

We all do :-(

we only deal with problems that are reproducible

Being amenable to insight apart from evidence is also productive. I don't need to see someone falling into a hole to realise that the hole should be closed.

Having said that, I wrote a program that writes a program and found a test case:

bug-report.cpp

Please compile with:
binl/wpp -bt=dos -0 -ml -wx -oa -oe -oh -oi+ -ok -ol -os -ox -oz -s -zm -zq bug-report.cpp

Observe that the March and April compiler versions produce different output.