[Bug tree-optimization/89059] Once we emit switchconf tables, we don't optimize them anymore

[Bug tree-optimization/89059] Once we emit switchconf tables, we don't optimize them anymore

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2019-01-25 00:00:00         |2021-8-28

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
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

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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.