[Bug tree-optimization/94617] Simple if condition not optimized

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #6)
> (In reply to David Seifert from comment #5)
> > just benchmarked the code on an oldish Ivybridge. GCC with vanilla_bandpass
> > is 2.1x slower than GCC with funky_bandpass, and GCC with funky_bandpass is
> > 12% slower than Clang with vanilla_bandpass.
> 
> It really depends, conditional moves are really badly implemented in x86 and
> sometimes they do improve speed and at other times they slow things down by
> huge amounts, which mostly depends on how well the CPU can predict branches
> if there are (if well, then branches are significantly faster, if they are
> very badly predictable, then conditional moves are faster).
> 
> As for turning it into
> (unsigned)x - a < (unsigned)b - a
> reassoc has
> optimize_range_tests_var_bound
> which right now handles
>    a >= 0 && a < b into (unsigned) a < (unsigned) b
>    a >= 0 && a <= b into (unsigned) a <= (unsigned) b
> Now
>    a >= b && a < c into (unsigned) a - b < (unsigned) c - b
> isn't equivalent to that, e.g. if b is 5 and c 4.

sure, there are extra constraints that a <= b and the unsigned type
has to have 1 bit more precision.  So if we would want to do this
transform then we'd need symbolic range info constraining a and b
appropriately.