[PATCH][middle-end/88784] Middle end is missing some optimizations about unsigned
Jeff Law
law@redhat.com
Thu Jun 27 15:48:00 GMT 2019
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 <helijia@linux.ibm.com>
> Qi Feng <ffengqi@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
More information about the Gcc-patches
mailing list