https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64454
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Marc Glisse from comment #6) > (In reply to Jakub Jelinek from comment #5) > > The reason for tree_int_cst_sgn (vr->min) >= 0 was that I don't want to let > > 0 through and for negative values, handling those would require computing > > absolute value, but as match.pd already folds x % -5 already into x % 5, > > there is no need to bother with it, so I'm just trying to play safe. > > I don't think we are talking about the same thing. Restricting to positive > op1 is good. What I find a little strange is: > > + if (TYPE_UNSIGNED (TREE_TYPE (op0)) > + || tree_int_cst_sgn (vr->min) >= 0 > + || tree_int_cst_lt (fold_unary (NEGATE_EXPR, TREE_TYPE (op1), op1), > + vr->min)) > > where condition 2: min>=0 is more restrictive than condition 3: min>-op1 > (since op1 is known to be positive) so we could skip condition 2. Ah, this, I just didn't want to call fold_unary to create GC garbage when I can cheaply see that it is ok. If I were to remove something, the TYPE_UNSIGNED (TREE_TYPE (op0)) check could go (as tree_int_csg_sgn (vr->min) will be then >= 0 always).
