It seems like optimization cases where this makes sense are generally of the sort where `noreturn` can't be used because it is conditional. That makes sense to

It seems like optimization cases where this makes sense are generally of the sort where `noreturn` can't be used because it is conditional. That makes sense to me (although, could this have covered most use cases by making `noreturn` support being passed the name of a function argument?). One example was interesting, though. I could see someone believing these might produce the same optimized assembly (-O2): void a(int& x, int& y) { if (&x == &y) __builtin_unreachable(); x ^= y; y ^= x; x ^= y; } void b(int& __restrict x, int& __restrict y) { x ^= y; y ^= x; x ^= y; } However, it produces: a(int&, int&): # @a(int&, int&) mov eax, dword ptr [rdi] xor eax, dword ptr [rsi] mov dword ptr [rdi], eax xor eax, dword ptr [rsi] mov dword ptr [rsi], eax xor dword ptr [rdi], eax ret b(int&, int&): # @b(int&, int&) mov eax, dword ptr [rsi] mov ecx, dword ptr [rdi] mov dword ptr [rsi], ecx mov dword ptr [rdi], eax ret Is this something compiler contributors would optimize once they know about it? Similar question probably exists with using `__builtin_unreachable` if values aren't aligned versus `__builtin_assume_aligned`. I'd love to see these things illustrated with more real-world examples.