Similar to JDK-8318889, we should evaluate if we have other fatal asserts in C2 that detect situations we can't recover from, i.e. that (could) lead to a crash in product, and that we (often) hit in the past. If their detection is feasible and not too expensive in release builds, we should add compilation bailouts.

Examples:
- loopnode.cpp:155: assert(false) failed: Bad graph detected in get_early_ctrl_for_expensive JDK-8229994
- loopnode.hpp:1140: assert(n != nullptr) failed: Bad immediate dominator info JDK-8314024, JDK-8319372
- matcher.cpp:1591: assert(false) failed: bad AD file JDK-8289043 (I think we've never seen this with crashes in product but it seems to be cheap enough to bail out anyway)
- loopnode.cpp:5665: assert(!had_error) failed: bad dominance or "Bad graph detected in compute_lca_of_uses" JDK-8318690 (This seems very expensive though but lead to crashes in the past, see JDK-8078262)
- gcm.cpp:276: assert(false) failed: unscheduable graph JDK-8283466 (might be too expensive but we've seen crashes in the past JDK-8218961)
- loopopts.cpp:1598: assert(!n->is_Store() && !n->is_LoadStore()) failed: no node with a side effect JDK-8286625

Probably harmless but we should verify:
- gcm.cpp:830: assert(store->find_edge(load) != -1) failed: missing precedence edge JDK-8265132
- chaitin.cpp:1661: "No dead instructions after post-alloc" and postaloc.cpp:140: "unexpected yanked node" JDK-8210389

Feel free to add to this list.