This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFA] Reimplement canonicalization of comparison arguments in match.pd
- From: Marc Glisse <marc dot glisse at inria dot fr>
- To: Jeff Law <law at redhat dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Sat, 30 May 2015 11:57:11 +0200 (CEST)
- Subject: Re: [RFA] Reimplement canonicalization of comparison arguments in match.pd
- Authentication-results: sourceware.org; auth=none
- References: <55693F80 dot 9070805 at redhat dot com>
- Reply-to: gcc-patches at gcc dot gnu dot org
On Fri, 29 May 2015, Jeff Law wrote:
c-common.c::shorten_compare has code to canonicalize the arguments of a
comparison so that the constant is the second argument. This patch removes
the implementation from c-common.c and instead implements it in match.pd.
Note the match.pd tries to match the prior behavior of shorten_compare, hence
the strange handling of zero. No justification exists AFAIK for that strange
handling in shorten_compare.
The match.pd pattern is primarily Kai's -- I just took the 4 patterns he
wrote and squashed them into a single pattern to avoid the test duplication.
The xfailed testcase is only case I saw across my comparison tests where this
change regressed. Basically shorten-compare had something non-canonical when
called. It was able to canonicalize, then optimize the result. I just
wanted a record of that test in the testsuite. Obviously if we hit our goal
of implementing everything from shorten_compare, that test will no longer
need to be xfailed :-)
Bootstrapped and regression tested on x86-linux-gnu. OK for the trunk?
I understand doing it in 2 commits to better see what regresses, but I
don't think we should keep the weirdness in match.pd.
Does it regress anything if we instead add inside the for loop that
follows /* -A CMP -B -> B CMP A. */
(simplify
(cmp CONSTANT_CLASS_P@0 @1)
(scmp @1 @0))
? If we want to inhibit in some cases because we fail to fold to a
constant, or because COND_EXPR needs 1 != 0 or something, we can always
add checks:
(simplify
(cmp CONSTANT_CLASS_P@0 @1)
(if (!zerop (@1))
(scmp @1 @0)))
(hmm, I didn't add zerop to tree.[hc] yet) or !CONSTANT_CLASS_P (@1) or
whatever is necessary.
--
Marc Glisse