On Mon, Dec 09, 2019 at 10:54:34AM +0100, Marc Glisse wrote:
> On Fri, 6 Dec 2019, Jakub Jelinek wrote:
> 
> > --- gcc/match.pd.jj 2019-12-06 14:07:26.877749065 +0100
> > +++ gcc/match.pd    2019-12-06 15:06:08.042953309 +0100
> > @@ -2697,6 +2697,31 @@ (define_operator_list COND_TERNARY
> >   (cmp (minmax @0 INTEGER_CST@1) INTEGER_CST@2)
> >   (comb (cmp @0 @2) (cmp @1 @2))))
> > 
> > +/* Undo fancy way of writing max/min or other ?: expressions,
> > +   like a - ((a - b) & -(a < b)), in this case into (a < b) ? b : a.
> > +   People normally use ?: and that is what we actually try to optimize.  */
> > +(for cmp (simple_comparison)
> > + (simplify
> > +  (minus @0 (bit_and:c (minus @0 @1)
> > +                  (convert? (negate@4 (convert? (cmp@5 @2 @3))))))
> > +  (if (INTEGRAL_TYPE_P (type)
> > +       && INTEGRAL_TYPE_P (TREE_TYPE (@4))
> > +       && TREE_CODE (TREE_TYPE (@4)) != BOOLEAN_TYPE
> > +       && INTEGRAL_TYPE_P (TREE_TYPE (@5))
> > +       && (TYPE_PRECISION (TREE_TYPE (@4)) >= TYPE_PRECISION (type)
> > +      || !TYPE_UNSIGNED (TREE_TYPE (@4))))
> > +   (cond (cmp @2 @3) @1 @0)))
> 
> I was going to suggest
>  (cond @5 @1 @0)
> 
> and possibly replacing (cmp@5 @2 @3) with truth_valued_p@5, before
> remembering that COND_EXPR embeds the comparison, and that not transforming
> when we don't see the comparison is likely on purpose. Plus, if @5 was in a
> signed 1-bit type, it may look more like -1 than 1 and break the
> transformation (is that forbidden as return type of a comparion?).

FYI, I've already committed the patch, so any improvement or bugfix needs to
be done incrementally.
The comparison in there was mainly an attempt to have a truth value
in there, so maybe truth_valued_p would work too, maybe even a
get_range_info checked value of [0, 1] would, though perhaps just
truth_valued_p is better because it involves some kind of setcc-like
instruction in the end.  All I'd like to see for comparisons is that they
are in the COND_EXPR's first operand if they can't throw.
I'm afraid I have no idea whether we can have signed 1-bit truth_valued_p
operations and what will happen with them, if it is possible, then I guess
an additional condition will be needed, check that it has prec > 1 or
TYPE_UNSIGNED.

        Jakub

Reply via email to