On 2019/7/1 3:30 PM, Richard Biener wrote: > On Fri, 28 Jun 2019, Andrew Pinski wrote: > >> On Thu, Jun 27, 2019 at 9:55 PM Li Jia He wrote: >>> >>> >>> >>> On 2019/6/27 11:48 PM, Jeff Law wrote: >>>> On 6/27/19 12:11 AM, Li Jia He wrote: >>>>> Hi, >>>>> >>>>> According to the optimizable case described by Qi Feng on >>>>> issue 88784, we can combine the cases into the following: >>>>> >>>>> 1. x > y && x != XXX_MIN --> x > y >>>>> 2. x > y && x == XXX_MIN --> false >>>>> 3. x <= y && x == XXX_MIN --> x == XXX_MIN >>>>> >>>>> 4. x < y && x != XXX_MAX --> x < y >>>>> 5. x < y && x == XXX_MAX --> false >>>>> 6. x >= y && x == XXX_MAX --> x == XXX_MAX >>>>> >>>>> 7. x > y || x != XXX_MIN --> x != XXX_MIN >>>>> 8. x <= y || x != XXX_MIN --> true >>>>> 9. x <= y || x == XXX_MIN --> x <= y >>>>> >>>>> 10. x < y || x != XXX_MAX --> x != UXXX_MAX >>>>> 11. x >= y || x != XXX_MAX --> true >>>>> 12. x >= y || x == XXX_MAX --> x >= y >>>>> >>>>> Note: XXX_MIN represents the minimum value of type x. >>>>> XXX_MAX represents the maximum value of type x. >>>>> >>>>> Here we don't need to care about whether the operation is >>>>> signed or unsigned. For example, in the below equation: >>>>> >>>>> 'x > y && x != XXX_MIN --> x > y' >>>>> >>>>> If the x type is signed int and XXX_MIN is INT_MIN, we can >>>>> optimize it to 'x > y'. However, if the type of x is unsigned >>>>> int and XXX_MIN is 0, we can still optimize it to 'x > y'. >>>>> >>>>> The regression testing for the patch was done on GCC mainline on >>>>> >>>>> powerpc64le-unknown-linux-gnu (Power 9 LE) >>>>> >>>>> with no regressions. Is it OK for trunk ? >>>>> >>>>> Thanks, >>>>> Lijia He >>>>> >>>>> gcc/ChangeLog >>>>> >>>>> 2019-06-27 Li Jia He >>>>> Qi Feng >>>>> >>>>> PR middle-end/88784 >>>>> * gimple-fold.c (and_comparisons_contain_equal_operands): New function. >>>>> (and_comparisons_1): Use and_comparisons_contain_equal_operands. >>>>> (or_comparisons_contain_equal_operands): New function. >>>>> (or_comparisons_1): Use or_comparisons_contain_equal_operands. >>>> Would this be better done via match.pd? ISTM this transformation would >>>> be well suited for that framework. >>> >>> Hi, Jeff >>> >>> I did this because of the following test case: >>> ` >>> _Bool comp(unsigned x, unsigned y) >>> { >>> return x > y && x != 0; >>> } >>> ` >>> The gimple file dumped on the power platform is: >>> ` >>> comp (unsigned int x, unsigned int y) >>> { >>> _Bool D.2837; >>> int iftmp.0; >>> >>> if (x > y) goto ; else goto ; >>> : >>> if (x != 0) goto ; else goto ; >>> : >>> iftmp.0 = 1; >>> goto ; >>> : >>> iftmp.0 = 0; >>> : >>> D.2837 = (_Bool) iftmp.0; >>> return D.2837; >>> } >>> ` >>> However, the gimple file dumped on x86 is >>> ` >>> comp (unsigned int x, unsigned int y) >>> { >>> _Bool D.2837; >>> >>> _1 = x > y; >>> _2 = x != 0; >>> _3 = _1 & _2; >>> _4 = (int) _3; >>> D.2837 = (_Bool) _4; >>> return D.2837; >>> } >>> ` >>> >>> The reason for the inconsistency between these two behaviors is param >>> logical-op-non-short-circuit. If we add the pattern to the match.pd >>> file, we can only optimize the situation in which the statement is in >>> the same basic block (logical-op-non-short-circuit=1, x86). But for >>> a cross-basic block (logical-op-non-short-circuit=0, power), match.pd >>> can't handle this situation. >>> >>> Another reason is that I found out maybe_fold_and_comparisons and >>> maybe_fold_or_comparisons are not only called by ifcombine pass but >>> also by reassoc pass. Using this method can basically unify param >>> logical-op-non-short-circuit=0 or 1. >> >> >> As mentioned before ifcombine pass should be using gimple-match >> instead of fold_build. Try converting ifcombine over to gimple-match >> infrastructure and add these to match.pd. > > Yes, I mentioned that in the PR. The issue is that at the moment > to combine x > y with x <= y you'd have to build GENERIC trees > for both or temporary GIMPLE assign with a SSA def (and then feed > that into the GENERIC or GIMPLE match.pd path). Hi, I did some experimentation using ‘temporary GIMPLE with a SSA def (and then feed that into the GIMPLE match.pd path’. Could we consider the code in the attachment(I did a test and the code took effect)? Thanks, Lijia He > > maybe_fold_and/or_comparisons handle two exploded binary expressions > while the current match.pd entries handle at most one exploded one > (the outermost then, either AND or OR). But it would be definitely > doable to auto-generate maybe_fold_and/or_comparisons from match.pd > patterns which is what I'd ultimatively suggest to do (in some more > generalized form maybe). Either with a separate genmatch invocation > or as part of the --gimple processing (not sure what is more feasible > here). > > I told Li Jia He that I don't expect him to do this work. > > Note I didn't review the actual patch yet. > > Thanks, > Richard. >