https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63464
--- Comment #2 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 6 Oct 2014, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63464 > > Jakub Jelinek <jakub at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|UNCONFIRMED |NEW > Last reconfirmed| |2014-10-06 > CC| |jakub at gcc dot gnu.org, > | |rguenth at gcc dot gnu.org, > | |steven at gcc dot gnu.org > Ever confirmed|0 |1 > > --- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > We have this optimization implemented for switches, if you compile > char*f3(char*s){ > do > { > switch (*s) > { > case ' ': > case ',': > case '\r': > case '\n': > ++s; > continue; > default: > return s; > } > } > while (1); > } > > then it will do the bit test, see r189173 (and various follow-up fixes for > that). > Now, we can argue whether in this case it is beneficial to perform the > MINUS_EXPR or if maxval is small enough (e.g. when maxval is smaller than > BITS_PER_WORD), just assume minval is 0. > > And then the question is, if we should teach reassoc range optimizations to > reuse emit_case_bit_tests, or convert such tests into a GIMPLE_SWITCH and > expand as such. > > Richard/Steven, thoughts about this? Factoring out the code-gen part of switch-conversion and use it from reassoc range optimization? I don't think creating a GIMPLE_SWITCH from reassoc is a good idea (given that switch conversion runs early). Richard.
