[RFA] Reimplement canonicalization of comparison arguments in match.pd
Marc Glisse
marc.glisse@inria.fr
Sat May 30 15:10:00 GMT 2015
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
More information about the Gcc-patches
mailing list