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 <heli...@linux.ibm.com> > Qi Feng <ffen...@linux.ibm.com> > > 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.
jeff
