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.

Attempting to emulate restricted with __builtin_unreachable has been one of the first thing I tried when I learned about unreachable. I periodically try again, but generally I have been underwhelmed with trying to give gcc value range informations with it.

Technically these would still produce different results if y started two bytes after x -- I can't remember if that is itself legal however!

No that wouldn't be legal. Distinct objects can't partially overlap, unless one is a subject of the other.