[Bug tree-optimization/89059] Once we emit switchconf tables, we don't optimize them anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89059 --- Comment #4 from Jakub Jelinek --- It is way too early, but on the other side the inlining decisions want to know if the switch is optimizable in certain way. So one possibility would be to lower as we currently do, but add optimizations to simplify and/or convert to some other form later after IPA. And another would be to just do the analysis phase of switches shortly before inlining and note (either in flags on GIMPLE_SWITCH or in an on-the-side data structure or whatever) what way we'd optimize the switch, take it into account during inlining cost computations and lower for real after IPA only. Though, e.g. if we decide to go with a value table for a switch in an inline function and if in all the inline copies we still decide to use the same value table, it would be nice to share the tables. But, if in each inlined copy VRP has different ranges and we can build different tables, we shouldn't share them... And there is another PR that we should use range info (ranger at this point) in the switch lowering decisions.
[Bug tree-optimization/89059] Once we emit switchconf tables, we don't optimize them anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89059 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2019-01-25 00:00:00 |2021-8-28 --- Comment #3 from Andrew Pinski --- I wonder if we are doing switch table to const table too early. Doing it before inlining might seem too early.
[Bug tree-optimization/89059] Once we emit switchconf tables, we don't optimize them anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89059 --- Comment #2 from Jakub Jelinek --- Ulrich (CCed) reported that. If the __builtin_unreachable hint is inside of foo, we do optimize it properly.
[Bug tree-optimization/89059] Once we emit switchconf tables, we don't optimize them anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89059 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-25 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed! Clang has the same problem. We at least fold away the guard check. How did you come to it Jakub?
