This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
--


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]