4 ms·
> AFAIK clang will usually just treat a signed overflow as an unsigned overflow when optimizing as it simplifies things. This was a bit of a surprise to me; I
by aw1621107 5y ago
> AFAIK clang will usually just treat a signed overflow as an unsigned overflow when optimizing as it simplifies things.
This was a bit of a surprise to me; I thought that Clang could use the presence of signed overflow to infer bounds, like when it "breaks" naïve overflow checks. I didn't know about the treat-signed-as-unsigned behavior you described.
If that's what clang is doing, that's pretty neat! Quite a bit of reasoning to work through there.
Thanks for taking the time to explain!
- int_19h 5y agoTreat-signed-as-unsigned is what you get "by default" with a two's complement representation of integers, if you just use ADD/SUB opcodes regardless of the type (i.e. the cheapest/fastest way to do it).
- aw1621107 5y agoRight, but I had thought that clang would have done something involving deducing the bounds of n, which could be used to avoid overflow in later optimizations. Now that I think about it, though, they key there is "could" - overflow could be avoided by deducing bounds, but if said deduction can't occur then what you describe sounds like the most natural action to take as long as there aren't other issues.