This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix PR 23049
- From: Roger Sayle <roger at eyesopen dot com>
- To: Andrew Pinski <pinskia at physics dot uc dot edu>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Sat, 17 Sep 2005 15:32:23 -0600 (MDT)
- Subject: Re: [PATCH] Fix PR 23049
On Sat, 17 Sep 2005, Andrew Pinski wrote:
> The problem here is that we get in fold the following expression:
> 0 == 0 ? 0 : 1
> We go into an infinite calling fold over and over again.
>
> There are a couple of ways fixing this:
> 1. Call fold on arg0 when we have a COND_EXPR.
> 2. Make sure that fold does not go into an infinite loop.
> 3. fold the EQ_EXPR before getting into fold.
>
> The problem with 3, is that in DOM, we replace, a with 0 where
> the original expression was "a == 0 ? 0 : 1" so DOM is just
> replacing an expression with its value and should not be the
> one who is folding the expression.
Unfortunately, the correct answer is "3.", and it is the
responsibility of whoever creates or modifies a tree to fold
it (c.f. the fold_buildN idiom). In RTL-land, the compiler
uses simplify_replace_rtx to substitute a constant into an
rtx, and DOM/CSE/GCSE and others should be doing something
similar on trees, if they aren't already.
One of the invariants of "fold" is that all of a tree's operands
(subtrees) have already been folded/canonicalized before calling fold.
Indeed, this keeps fold from being quadratic and simplifies much of
its pattern matching. Alas, although simple, your one-line fix will
introduce severe compile-time performance issues on pathological
source files. ((a?b:c)?d:e)?f:g...
Roger
--