←back to thread

305 points todsacerdoti | 3 comments | | HN request time: 0s | source
Show context
mmastrac ◴[] No.44061671[source]
The associated issue for comparing two u16s is interesting.

https://github.com/rust-lang/rust/issues/140167

replies(3): >>44061906 #>>44065911 #>>44066028 #
rhdjsjebshjffn ◴[] No.44065911[source]
This just seems to illustrate the complexity of compiler authorship. I am very sure c compilers are wble to address this issue any better in the general case.
replies(2): >>44066162 #>>44066204 #
1. vlovich123 ◴[] No.44066204[source]
The rust issue has people trying this with c code and the compiler generates the same issue. This will get fixed and it’ll help c and Rust code
replies(1): >>44068993 #
2. runevault ◴[] No.44068993[source]
Out of curiosity just clang or gcc as well?
replies(1): >>44072736 #
3. josephg ◴[] No.44072736[source]
I just tried it, and the problem is even worse in gcc.

Given this C code:

    typedef struct { uint16_t a, b; } pair;

    int eq_copy(pair a, pair b) {
        return a.a == b.a && a.b == b.b;
    }
    int eq_ref(pair *a, pair *b) {
        return a->a == b->a && a->b == b->b;
    }
Clang generates clean code for the eq_copy variant, but complex code for the eq_ref variant. Gcc emits pretty complex code in both variants.

For example, here's eq_ref from gcc -O2:

    eq_ref:
        movzx   edx, WORD PTR [rsi]
        xor     eax, eax
        cmp     WORD PTR [rdi], dx
        je      .L9
        ret
    .L9:
        movzx   eax, WORD PTR [rsi+2]
        cmp     WORD PTR [rdi+2], ax
        sete    al
        movzx   eax, al
        ret
Have a play around: https://c.godbolt.org/z/79Eaa3jYf