[Bug c/68274] New: __builtin_unreachable pessimizes code

[matt at godbolt dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68274

            Bug ID: 68274
           Summary: __builtin_unreachable pessimizes code
           Product: gcc
           Version: 5.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: matt at godbolt dot org
  Target Milestone: ---

While experimenting with __builtin_unreachable I found that in some cases
adding it pessimizes the code. Consider the following code (also at
https://goo.gl/WmR8PX):

--
enum Side { Bid, Ask };
struct Foo {  int a;  int b; };

int test(Side side, const Foo &foo) {
  if (side == Bid) return foo.a;
  return foo.b;
}

int test_with_unreach(Side side, const Foo &foo) {
  if (side == Bid) return foo.a;
  if (side != Ask) __builtin_unreachable();
  return foo.b;
}
--

In the non-unreachable case `test`, the code generates the cmove I'd expect:

--
test(Side, Foo const&):
        mov     eax, DWORD PTR [rsi+4]
        test    edi, edi
        cmove   eax, DWORD PTR [rsi]
        ret
--

In the unreachable case, GCC resorts back to branching:

--
test_with_unreach(Side, Foo const&):
        test    edi, edi
        je      .L9
        mov     eax, DWORD PTR [rsi+4]
        ret
.L9:
        mov     eax, DWORD PTR [rsi]
        ret
--

It's not really clear to me how much of a pessimization this is; but it was
surprising that the unreachability had such an effect.

I was hoping to prove to the compiler that the only valid inputs were "Bid" and
"Ask" and as such it could actually generate something like:

--
mov eax, DWORD PTR[rsi+eax*4]
ret
--