https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88784
--- Comment #17 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 24 May 2019, glisse at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88784 > > --- Comment #16 from Marc Glisse <glisse at gcc dot gnu.org> --- > (In reply to rguent...@suse.de from comment #15) > > It can matter because we might have gimplified the && to > > control flow. > > Indeed. You want to look at the forwprop1 dump to see what gimple-match would > need to match (and does match on x86_64). > > When X > Y && X != 0 is represented with control flow, in theory, VRP could > deduce a range [1,inf] for X from X>Y, but in practice it uses a symbolic > range > [y_3(D) + 1, +INF] from which we fail to deduce X!=0. I think the new ranger > thing that doesn't try to do symbolic ranges would handle that better ;-) Note that in theory the ifcombine pass should pick up the opportunity to simplify the comparison via maybe_fold_and_comparisons. It looks like that code is quite old and could need a rewrite to match-and-simplify. But of course it exists to avoid creating trees for the combination parts which still has a point in match-and-simplify times. An opportunity for an alternate code-generator from match.pd since the patterns are still valid sources for the transform just the input is bigger exploded forms.
