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
--
