Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Comparison operations are basic primitives that usually store their result into a register.

In one of the most common processor architectures (the x86 family), comparison operations do store their result into a register, but it's the flags register, which can't be used directly in arithmetic operations. So you have to follow a comparison operation with either a conditional branch or a conditional move (and earlier processors in the x86 family didn't have conditional moves).

> So I guess my question is, while it’s technically possible for a compiler to compile this into a branching operations, under what circumstances would a compiler actually choose to do that, given there’s isn’t a clear benefit?

It depends on the compiler heuristics and on the surrounding code; for instance, it might decide that "compare; conditional branch over next instruction; increment" is better than "copy to second register; increment second register; compare; conditional move from second register", because it uses one less register (the x86 family is register starved) and one less instruction (relevant when optimizing for size).



> So you have to follow a comparison operation with either a conditional branch or a conditional move (and earlier processors in the x86 family didn't have conditional moves).

The x86 family has the `setCC` instructions [^1] that move bits from the flag register to a general purpose one. Example from godbolt, see `setg`:

https://c.godbolt.org/z/MY37oP9vz

[^1]: https://www.felixcloutier.com/x86/setcc


SETcc is indeed what GCC typically uses. You can also play tricks with the carry flag and ADC but I don't think I have ever seen GCC do it.


The latest version can [^1], though anecdotally I've seen clang/LLVM being smarter about it.

[^1]: https://c.godbolt.org/z/vP8edfen7




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: