2026-10-09 04:07 UTC
Replies (2)
-
@dougall@mastodon.social 2026-10-09 04:19
@curious@floss.social @fay59@tech.lgbt Cheaper, more debuggable assertions, yep. There was a good discussion of benefits that forked off earlier in the thread (from 2023, when this was hypothetical): https://mastodon.social/@fay59@tech.lgbt/110568094482027713 Having all the compare/test forms makes it even cheaper than just trapping on a flag condition, which I what I was imagining before, which is very nice.
-
@fay59@tech.lgbt 2026-10-09 05:18
@curious@floss.social @dougall@mastodon.social with -fbounds-safety as an example, there is a tradeoff between code size/performance and debuggability of bounds checks: right now the compiler either emits a single trap instruction at the end of your function (with all failing checks going there) or it emits one trap per check and jumps over it if not taken. You lose debuggability with the former because when your program hits the trap, you don’t know where you came from so you don’t have a source location. You lose on code size and performance with the latter. In all cases, the checks also pollute the branch predictor as you essentially always expect that the branch is not taken