This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][middle-end/88784] Middle end is missing some optimizations about unsigned
- From: Richard Biener <rguenther at suse dot de>
- To: Li Jia He <helijia at linux dot ibm dot com>
- Cc: Andrew Pinski <pinskia at gmail dot com>, Jeff Law <law at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Segher Boessenkool <segher at kernel dot crashing dot org>, wschmidt at linux dot ibm dot com, Martin Liska <mliska at suse dot de>
- Date: Thu, 5 Sep 2019 15:17:02 +0200 (CEST)
- Subject: Re: [PATCH][middle-end/88784] Middle end is missing some optimizations about unsigned
- References: <1561615913-22109-1-git-send-email-helijia@linux.ibm.com> <6fb28248-5134-cec5-5045-45253e4d2eb0@redhat.com> <6d333ccf-9905-e929-c2dc-fc611ff929f1@linux.ibm.com> <CA+=Sn1mgUXkEBQTzp5Nv5gcANtpZeutisEtQbez_L7xgg39ppw@mail.gmail.com> <alpine.LSU.2.20.1907010920230.10704@zhemvz.fhfr.qr> <bc69c05f-d966-cab7-b79f-a188523f9258@linux.ibm.com> <alpine.LSU.2.20.1907021007050.2976@zhemvz.fhfr.qr> <alpine.LSU.2.20.1907021031040.2976@zhemvz.fhfr.qr> <845bc280-7bd6-509b-3830-4ebde50f1b20@linux.ibm.com>
On Tue, 16 Jul 2019, Li Jia He wrote:
> Hi,
>
> I made some changes based on the recommendations. Would you like to
> help me to see it again ? Sorry, it took so long time to provide the
> patch.
>
> Note: 1. I keep the code for and_comparisons_1 and or_comparisons_1.
> The reason is that I did not found a good way to handle the
> optimization of '((x CODE1 y) AND (x CODE2 y))' in match.pd.
> Maybe I missing some important information about match.pd.
> 2. The gimple_resimplify2 function is not used. Since stmt1,
> stmt2, lhs1 and lhs2 are allocated on the stack, Is there a
> question with the value on the stack as the return value ?
> I may have misunderstood Richard's intention.
And now for the match.pd patch.
+/* x > y && x != XXX_MIN --> x > y */
+(for and (truth_and bit_and)
+ (simplify
+ (and:c (gt:c@3 @0 @1) (ne @0 INTEGER_CST@2))
+ (if (INTEGRAL_TYPE_P (TREE_TYPE (@0)) && INTEGRAL_TYPE_P
(TREE_TYPE(@1))
+ && (wi::eq_p (wi::to_wide (@2), wi::min_value (TREE_TYPE (@2)))))
+ @3)))
+
+/* x > y && x == XXX_MIN --> false */
+(for and (truth_and bit_and)
+ (simplify
+ (and:c (gt:c @0 @1) (eq @0 INTEGER_CST@2))
+ (if (INTEGRAL_TYPE_P (TREE_TYPE (@0)) && INTEGRAL_TYPE_P
(TREE_TYPE(@1))
+ && (wi::eq_p (wi::to_wide (@2), wi::min_value (TREE_TYPE (@2)))))
+ { boolean_false_node; })))
you could merge those two via
(for eqne (eq ne)
(for and (....
(simplify
(and:c (gt:c @0 @1) (eqne @0 INTEGER_CST@2))
(if (...)
(switch
(if (eqne == NE_EXPR)
@3)
(if (eqne == EQ_EXPR)
{ constant_boolean_node (false, type); }))))
notice using constant_boolean_node (false, type); instead of
boolean_false_node. I suspect more unification is possible.
Also you could do
(match min_value
INTEGER_CST
(if (INTEGRAL_TYPE_P (type)
&& wi::eq_p (wi::to_wide (t), wi::min_value (type)))))
and then write
(simplify
(and:c (gt:c @0 @1) (eq @0 min_value))
(...
Your
(if (INTEGRAL_TYPE_P (TREE_TYPE (@0)) && INTEGRAL_TYPE_P
(TREE_TYPE(@1))
is redundant, it's enough to check either @0 or @1 given they
have to be compatible for the gt operation. Note you probably
want to use
(and:c (gt:c @0 @1) (eq @@0 min_value))
and verify that types_match (@1, @0) because when @0 are a constant
(and (eq @0 min_value) is not folded which can happen) then they
might have different types and thus you could have
(SHORT_MAX > intvar) && (SHORT_MAX == SHORT_MAX)
That said, the patterns can be quite a bit simplified I think.
Richard.