On Wed, Oct 22, 2025 at 1:26 AM Richard Biener
<[email protected]> wrote:
>
> On Wed, Oct 22, 2025 at 2:15 AM Andrew Pinski
> <[email protected]> wrote:
> >
> > This is the last patch that is needed to support to remove
> > minmax_replacement.
> > This fixes pr101024-1.c which is failing when minmax_replacement is removed.
> >
> > This next patch will remove it.
> >
> > gcc/ChangeLog:
> >
> > PR tree-optimization/101024
> > * match.pd (`((signed)a </>= 0) ? min/max (a, c) : b`): New pattern.
> > ---
> > gcc/match.pd | 21 +++++++++++++++++++++
> > 1 file changed, 21 insertions(+)
> >
> > diff --git a/gcc/match.pd b/gcc/match.pd
> > index a4248a521cf..c6e7850a46e 100644
> > --- a/gcc/match.pd
> > +++ b/gcc/match.pd
> > @@ -6911,6 +6911,27 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> > && integer_nonzerop (fold_build2 (GE_EXPR, boolean_type_node,
> > @3, @4)))
> > (max @2 @4))))))
> >
> > +/* Optimize (((signed)a CMP 0) ? max<a,CST2> : a */
> > +(for cmp (lt ge)
> > + minmax (min max)
> > + (simplify
> > + (cond (cmp:c (nop_convert @0) integer_zerop@1) (minmax:c@2 @0 @3) @4)
>
> why is @4 not @0 as in the comment above? Why do we need :c on the minmax
> when @3 is a constant? (and why's that not checked for?)
It was a copy and pasto in the comment when copied the previous pattern.
>
> > + (if (!TYPE_UNSIGNED (TREE_TYPE (@1)))
> > + (with
> > + {
> > + tree c1 = fold_convert (TREE_TYPE (@0), TYPE_MIN_VALUE (TREE_TYPE
> > (@1)));
>
> I'd prefer a wide_int_to_tree of the appropriate value rather than
> relying on TYPE_MIN_VALUE
Ok, will do
> here (but then ideally minmax_from_comparison wouldn't require a tree
> in the first place...).
The problem is minmax_from_comparison handles non-constants. I should
create a version which takes wide_int for this and have the tree
version call into it.
>
> > + tree_code ncmp = cmp == GE_EXPR ? LT_EXPR : GE_EXPR;
> > + tree_code code = minmax_from_comparison (ncmp, @0, c1, @0, @4);
> > + }
> > + (if (ncmp == LT_EXPR
> > + && code == MIN_EXPR
> > + && integer_nonzerop (fold_build2 (LE_EXPR, boolean_type_node,
> > @3, @4)))
>
> Err, can we please avoid building & folding trees here? Or at least
> it warrants some comment
> as to why this is necessary (esp. why not && (tem = fold_binary (...))
> && integer_nonzerop (tem)).
Ok, I used wi::le_p/wi::ge_p instead.
Thanks,
Andrew
>
> > + (min @2 @4)
> > + (if (ncmp == GE_EXPR
> > + && code == MAX_EXPR
> > + && integer_nonzerop (fold_build2 (GE_EXPR, boolean_type_node,
> > @3, @4)))
> > + (max @2 @4)))))))
> > +
> > #if GIMPLE
> > /* These patterns should be after min/max detection as simplifications
> > of `(type)(zero_one ==/!= 0)` to `(type)(zero_one)`
> > --
> > 2.43.0
> >
