[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