On 15/02/17 08:17, Jakub Jelinek wrote: > On Wed, Feb 15, 2017 at 08:06:16AM +0100, Richard Biener wrote: >> On February 14, 2017 9:04:45 PM GMT+01:00, Jakub Jelinek <ja...@redhat.com> >> wrote: >>> Hi! >>> >>> The following patch is an attempt to fix a regression where we no >>> longer >>> switch convert one switch because earlier optimizations turn it into >>> unsupported shape. >> >> Is that because of early threading? > > Yes. > >>> and expects to be optimized into return 3 by vrp1. As switchconv is >>> earlier >>> than that, vrp1 sees: >>> _1 = a_3(D) & 1; >>> _4 = (unsigned int) _1; >>> _5 = CSWTCH.1[_4]; >>> return _5; >>> and doesn't optimize it. If the testcase had say case 7: replaced with >>> default:, it wouldn't pass already before. >> >> That looks odd... > > Just a pass ordering issue. > >> If the patch is ok, what >>> should >>> we do with vrp40.c? Change it in some way (e.g. return variable in one >>> case) so that switchconv doesn't trigger, or add an optimization in vrp >>> if we see a load from constant array with known initializer and the >>> range >>> is small enough and contains the same value for all those values, >>> replace >>> it with the value? >> >> Possibly, but for GCC 8. > > To both this switchconv patch and the potential improvement for loading > from const arrays (can create an enhancement PR for that), or just the > latter?
Both I think - the patch is pretty big. Maybe we can instead make early threading not mess this up? >> can we teach EVRP about this? It runs before switch conversion. > > I guess so. It is a matter of calling simplify_switch_using_ranges > and then doing some cleanup (you wrote that optimization) > - to_update_switch_stmts handling. Sounds like a good thing to do (for GCC 8 as well). Thanks, Richard. > > Jakub >