This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch match.pd c c++]: Ignore results of 'shorten_compare' and move missing patterns in match.pd
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Kai Tietz <ktietz70 at googlemail dot com>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Jeff Law <law at redhat dot com>
- Date: Tue, 15 Sep 2015 14:56:02 +0000
- Subject: Re: [patch match.pd c c++]: Ignore results of 'shorten_compare' and move missing patterns in match.pd
- Authentication-results: sourceware.org; auth=none
- References: <CAEwic4ZDJHyst_kgSgMxZLtRtHEbyFUoCS1g5CPGkf6isR8GAA at mail dot gmail dot com> <CAFiYyc0iTJNkXc7t5q0afhow6Haf=QjY0gK2R_=9eCXHmWFPRg at mail dot gmail dot com> <CAEwic4ZGwzjRAO+Lw2+aLmeQ8eVxB8AoXcGDOwi3Ti4f8C4vhA at mail dot gmail dot com>
On Tue, 15 Sep 2015, Kai Tietz wrote:
> >> +/* Simplify '(type) X cmp CST' to 'X cmp (type-of-X) CST', if
> >> + CST fits into the type of X. */
> >> +(for cmp (simple_comparison)
> >> + (simplify
> >> + (cmp (convert@2 @0) INTEGER_CST@1)
> >
> > what about REAL_CSTs?
>
> Well, for fast-math this might be something to be extended. So I
> handled here just the common variant.
I don't think it needs fast-math, if the conversion (convert@2 @0) is a
floating-point extension (all values in the source type exactly
representable in the destination type[*]), although there are lots of
cases to consider and it makes sense to address such issues separately.
But, for example, for "float f;", it's always valid to convert "((double)
f) > 0.5" to "f > 0.5f". In fact, we already have such folding in
match.pd, "Fold (double)float1 CMP (double)float2 into float1 CMP
float2.", albeit with hard-coded references to float and double that seem
less than ideal. (If the constant isn't exactly representable in the
source type then the constant needs to be rounded in the correct direction
when shortening, but it's still always the case that there is a correct
conversion to a comparison in the narrower type.)
[*] If you care about exact underflow with traps enabled, you also need
subnormal source values to become normal destination values - removing a
conversion from x86 extended to __float128 could potentially remove an
exact underflow.
--
Joseph S. Myers
joseph@codesourcery.com