On Fri, Jun 4, 2021 at 4:18 PM Marc Glisse <marc.gli...@inria.fr> wrote: > > On Fri, 4 Jun 2021, Hongtao Liu via Gcc-patches wrote: > > > On Tue, Jun 1, 2021 at 6:17 PM Marc Glisse <marc.gli...@inria.fr> wrote: > >> > >> On Tue, 1 Jun 2021, Hongtao Liu via Gcc-patches wrote: > >> > >>> Hi: > >>> This patch is about to simplify (view_convert:type ~a) < 0 to > >>> (view_convert:type a) >= 0 when type is signed integer. Similar for > >>> (view_convert:type ~a) >= 0. > >>> Bootstrapped and regtested on x86_64-linux-gnu{-m32,}. > >>> Ok for the trunk? > >>> > >>> gcc/ChangeLog: > >>> > >>> PR middle-end/100738 > >>> * match.pd ((view_convert ~a) < 0 --> (view_convert a) >= 0, > >>> (view_convert ~a) >= 0 --> (view_convert a) < 0): New GIMPLE > >>> simplification. > >> > >> We already have > >> > >> /* Fold ~X op C as X op' ~C, where op' is the swapped comparison. */ > >> (for cmp (simple_comparison) > >> scmp (swapped_simple_comparison) > >> (simplify > >> (cmp (bit_not@2 @0) CONSTANT_CLASS_P@1) > >> (if (single_use (@2) > >> && (TREE_CODE (@1) == INTEGER_CST || TREE_CODE (@1) == VECTOR_CST)) > >> (scmp @0 (bit_not @1))))) > >> > >> Would it make sense to try and generalize it a bit, say with > >> > >> (cmp (nop_convert1? (bit_not @0)) CONSTANT_CLASS_P) > >> > >> (scmp (view_convert:XXX @0) (bit_not @1)) > >> > > Thanks for your advice, it looks great. > > And can I use *view_convert1?* instead of *nop_convert1?* here, > > because the original case is view_convert, and nop_convert would fail > > to simplify the case. > > Near the top of match.pd, you can see > > /* With nop_convert? combine convert? and view_convert? in one pattern > plus conditionalize on tree_nop_conversion_p conversions. */ > (match (nop_convert @0) > (convert @0) > (if (tree_nop_conversion_p (type, TREE_TYPE (@0))))) > (match (nop_convert @0) > (view_convert @0) > (if (VECTOR_TYPE_P (type) && VECTOR_TYPE_P (TREE_TYPE (@0)) > && known_eq (TYPE_VECTOR_SUBPARTS (type), > TYPE_VECTOR_SUBPARTS (TREE_TYPE (@0))) > && tree_nop_conversion_p (TREE_TYPE (type), TREE_TYPE (TREE_TYPE > (@0)))))) > Oh, it's restricted to the same number of elements which is not the case i tested. That's why nop_convert failed to simplify the case.
Guess we can define another nop1_convert to handle vector types with different number of elements, but still tree_nop_convertion_p? > So at least the intention is that it can handle both NOP_EXPR for scalars > and VIEW_CONVERT_EXPR for vectors, and I think we alread use it that way > in some places in match.pd, like > > (simplify > (negate (nop_convert? (bit_not @0))) > (plus (view_convert @0) { build_each_one_cst (type); })) > > (simplify > (bit_xor:c (nop_convert?:s (bit_not:s @0)) @1) > (if (tree_nop_conversion_p (type, TREE_TYPE (@0))) > (bit_not (bit_xor (view_convert @0) @1)))) > > (the 'if' seems redundant for this one) > > (simplify > (negate (nop_convert? (negate @1))) > (if (!TYPE_OVERFLOW_SANITIZED (type) > && !TYPE_OVERFLOW_SANITIZED (TREE_TYPE (@1))) > (view_convert @1))) > > etc. > > > At some point this got some genmatch help, to handle '?' and numbers, so I > don't remember all the details, but following these examples should work. > > -- > Marc Glisse -- BR, Hongtao