Can clang be convinced to optimize this almost-leaf function

Consider the following almost leaf function:

int almost_leaf(int* x) {
    if (__builtin_expect(*x >= 0, true)) {
        return *x;
    }
    return x_was_negative() + 1;
}

It is almost leaf in the sense that it is not strictly a leaf function (it may call x_was_negative is x is negative, but the __builtin_expect hints to the compiler that the return *x branch is usually taken, which involves no calls.

clang-16 compiles it like this:

almost_leaf(int*):                      # @almost_leaf(int*)
        push    rax
        mov     eax, dword ptr [rdi]
        test    eax, eax
        js      .LBB0_1
        pop     rcx
        ret
.LBB0_1:
        call    x_was_negative()
        inc     eax
        pop     rcx
        ret

The push and pop on the fast (expected) path (the part up to the first ret) are totally unnecessary here: the stack is unused, and no calls are made which require an aligned stack "due to ABI".

It would be better to just align the stack on the slow path where x_was_negative() is called, like gcc does:

almost_leaf(int*):
        mov     eax, DWORD PTR [rdi]
        test    eax, eax
        js      .L8
        ret
.L8:
        sub     rsp, 8
        call    x_was_negative()
        add     rsp, 8
        inc     eax
        ret

Can clang be convinced to compile this almost leaf function efficiently?

^{Note that clang can compile almost leaf functions without aligning the stack: e.g., if x is an int instead of int* it works, and if x_was_negative can be compiled as a tailcall it at also works (but trivially since no alignment is needed in that case at all).}

This optimization is now performed on the development version of Clang (trunk) and so it should be available in the next releases (certainly Clang 17.0). This can be seen on Godbolt. Here is the newly generated code:

almost_leaf(int*):
        mov     eax, dword ptr [rdi]
        test    eax, eax
        js      .LBB0_1
        ret
.LBB0_1:
        push    rax
        call    x_was_negative()@PLT
        inc     eax
        add     rsp, 8
        ret

As we can see, the fast path is the same.

Note that the initial unoptimized LLVM-IR is about the same for the two versions of Clang, but the last low-level optimizations steps results in slightly different results for this code. More specifically, a deep analysis of the LLVM-IR optimization steps performed shows that Clang 16 missed an optimization during the "Prologue/Epilogue Insertion & Frame Finalization" optimization step (a.k.a. "prologepilog"). This optimization is done even in -O1 in the development version of Clang. This optimization step can be seen on Godbolt.