https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87925
--- Comment #6 from Martin Liška <marxin at gcc dot gnu.org> --- (In reply to Eyal Rozenberg from comment #5) > (In reply to Martin Liška from comment #3) > > Currently we only do switch -> balanced decision tree (read series of > > if-then-else statements). Well definitely a potentially enhancement, > > question is whether it worth doing that.. > > That is a question for another bug. I'm just saying that these two cases (or > some expansion thereof, e.g. with some fallthrough on the case side, or with > several distinct values in each if statement) should be treated the same. > i.e. whatever optimizations are considered for one of them should be > considered for the other. Sure, agree with that. > > (In reply to Martin Liška from comment #4) > > This is not problem because it's a const expression that is evaluate in C++ > > front-end. Thus you don't get any penalty. > > The specific use example at the link is a static_assert, but the in() > function there works with runtime values as well. So - not just compile-time > computation. Another example - un-type-erasure dispatches, which may go into > tight loops: https://stackoverflow.com/a/38924396/1593077 Indeed.
