[Committed] Complex comparison folding tweaks

Roger Sayle roger@eyesopen.com
Fri Mar 9 23:56:00 GMT 2007


Whilst looking at PR middle-end/30433, I noticed some minor improvements
that could be made to the solution checked into mainline (that I'd missed
during my review).  Firstly, we shouldn't really be testing for either
EQ_EXPR or NE_EXPR in fold_comparison.  The code in fold-const.c is
structured such that the equality operators (EQ_EXPR/NE_EXPR) are handled
in one "hunk" in fold_binary's "switch", and the ordering operators
(LT_EXPR, GE_EXPR, and friends) are handled in another.  The function
fold_comparison is used to implement/share transformations common to both.
So optimizations that apply only to EQ_EXPR/NE_EXPR can avoid testing
"code" by being placed in the appropriate place.

Secondly, for the current equality/inequality of two COMPLEX_CSTs, this
code should probably go in fold_relational_const, which is the routine
which is called to do classic "constant folding" (compile-time evaluation)
of comparisons that are two INTEGER_CSTs, two REAL_CSTs, two COMPLEX_CSTs
or two VECTOR_CSTs.  At the top of fold_binary, we check whether both
operands are constants, and most compile-time evaluation is handled there
(with simplifications, strength reductions and other transformations being
handled in the main switch).

However, whilst I was there I thought I'd add some other complex
comparison optimizations.  I agree fully with RTH's game plan of
implementing complex operations in vector hardware (or suitable optabs)
and support the approach of leaving lowering of complex operations until
tree-ssa's complex lowering pass or later, when more information is
available.  However, there are cases where we know at compile-time that a
complex comparison will always be true or false, and in such cases there's
little point in leaving these to be discovered in later passes.  For
example, 2.0+ix == 3.0+iy will always be false, independent of the
components "x" and "y".  Likewise,
it's probably beneficial to reduce (_Complex float)x == (_Complex float)y
to a single scalar comparison "x == y", that can be analyzed by the early
SSA passes.  Note this isn't performing lowering, only simplification.


The following patch has been tested on i686-pc-linux-gnu with a full "make
bootstrap", all default languages including Ada, and regression tested
with a top-level "make -k check" with no new failures.

Committed to mainline as revision 122767.


2007-03-09  Roger Sayle  <roger@eyesopen.com>

        * fold-const.c (fold_comparison): Remove compile-time evaluation of
        complex constant equality/inequality comparisons for here.
        (fold_binary) <EQ_EXPR>: Simplify complex comparisons that are
        known at compile-time or can be simplified to a scalar comparison.
        (fold_relational_const): Move compile-time evaluation of complex
        constant equality/inequality comparisons to here.

        * gcc.dg/fold-eqcmplx-1.c: New test case.


Roger
--
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patchf.txt
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20070309/9434a45c/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fold-eqcmplx-1.c
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20070309/9434a45c/attachment.c>


More information about the Gcc-patches mailing list