[missed-opt] [x86_64] Suboptimal movzx after inline assembly returning a byte

[purplesyringa]

Found while trying to implement a fast black-box primitive.

Godbolt

char f(char x) {
    asm("nop" : "+r"(x));
    return x * 3;
}

short g(short x) {
    asm("nop" : "+r"(x));
    return x * 3;
}

char h(char x) {
    return x * 3;
}

f(char):
        nop
        movzx   eax, dil
        lea     eax, [rax + 2*rax]
        ret

g(short):
        nop
        lea     eax, [rdi + 2*rdi]
        ret

h(char):
        lea     eax, [rdi + 2*rdi]
        ret

The line movzx eax, dil in f can be omitted (and, indeed, GCC omits it). I initially thought this was some kind of dependency-breaking optimization, but I'm not sure anymore. For one thing, it's not done for 16-bit numbers (g), which would seemingly suffer from the same issue. It is also not done in h, where the input to lea is the function argument, which by psABI has undefined top bits. If this is an optimization attempt, it seems more like a pessimization after inline assembly, which the author supposedly made as efficient as possible, and there's no way to opt out of the zero-extenion.

[purplesyringa]

Here's a slightly different snippet that has an unnecessary movsx for 16-bit inputs, but not 8-bit ones or 32-bit ones. It tries to observe the value of a 16-bit register within a loop:

short with_short(short x) {
    short t = 0;
    for (int i = 0; i < 100; i++) {
        x >>= 1;
        t += x;
    }
    return t;
}

with_short(short):
        mov     ecx, 100
        xor     eax, eax
.LBB1_1:
        movsx   edi, di  ; this is unnecessary
        shr     edi
        add     eax, edi
        dec     ecx
        jne     .LBB1_1
        ret

Godbolt

I'm probably missing something obvious. If 8-bit logic is fine with using dil here, why does 16-bit logic try to avoid di? I thought partial register stalls worked equivalently for 8-bit and 16-bit subregisters.

[llvmbot]

@llvm/issue-subscribers-backend-x86

Author: Alisa Sireneva (purplesyringa)

Found while trying to implement a fast black-box primitive.

Godbolt

char f(char x) {
    asm("nop" : "+r"(x));
    return x * 3;
}

short g(short x) {
    asm("nop" : "+r"(x));
    return x * 3;
}

char h(char x) {
    return x * 3;
}

f(char):
        nop
        movzx   eax, dil
        lea     eax, [rax + 2*rax]
        ret

g(short):
        nop
        lea     eax, [rdi + 2*rdi]
        ret

h(char):
        lea     eax, [rdi + 2*rdi]
        ret

The line movzx eax, dil in f can be omitted (and, indeed, GCC omits it). I initially thought this was some kind of dependency-breaking optimization, but I'm not sure anymore. For one thing, it's not done for 16-bit numbers (g), which would seemingly suffer from the same issue. It is also not done in h, where the input to lea is the function argument, which by psABI has undefined top bits. If this is an optimization attempt, it seems more like a pessimization after inline assembly, which the author supposedly made as efficient as possible, and there's no way to opt out of the zero-extenion.

[Explorer09]

If the return type of f were anything larger than char, then the zero extension cannot be omitted. The compiler assumes the upper bits of x register (i.e. RDI) is clobbered, thus it's correct to truncate the upper bits to fit the width of char.

I really wonder if this issue is worth fixing in the compiler's side. Because, whether the movzx is needed depends heavily on calling convention. And, I would personally refrain from using short for function return type anyway. Just use int, and that can save you a lot of trouble.

[purplesyringa]

The compiler assumes the upper bits of x register (i.e. RDI) is clobbered

Can I tell it that they are not clobbered? I'm not sure how I'm supposed to indicate that.

I could cast to int and then pass data to 32-bit black box implementation, but then this cast will incur the cost of unconditional movsx on entry to inline assembly.

I can't avoid < 32-bit data entirely because I'm working with type-generic code.

This feels like an expressivity gap to me.

[Explorer09]

The compiler assumes the upper bits of x register (i.e. RDI) is clobbered

Can I tell it that they are not clobbered? I'm not sure how I'm supposed to indicate that.

Use x as input register in the extended asm like this:

char f(char x) {
    asm("nop" : : "r"(x));
    return x * 3;
}

[purplesyringa]

Yeah, no, then the optimizer can assume the value hasn't changed, and that allows it to simplify benchmarking loops. I only want to assert that the high bits are intact, not the low bits. As far as I can tell, the only way to run microbenchmarks otherwise is to write the entire microbenchmarking loop in assembly...

[Explorer09]

Yeah, no, then the optimizer can assume the value hasn't changed, and that allows it to simplify benchmarking loops. I only want to assert that the high bits are intact, not the low bits. As far as I can tell, the only way to run microbenchmarks otherwise is to write the entire microbenchmarking loop in assembly...

Well, yes. The extended asm syntax can only assume that all bits of a register will be clobbered or none at all.

That's part of the reason I suggested to avoid short and char in register variables.