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?
> 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.
Jakub
