Re: non trivial constant folding

Hans-Bernhard Broeker <>
1 Feb 2001 17:40:23 -0500

          From comp.compilers

Related articles
[16 earlier articles]
Re: non trivial constant folding (Conor O'Neill) (2001-01-11)
Re: non trivial constant folding (2001-01-18)
Re: non trivial constant folding (2001-01-18)
Re: non trivial constant folding (2001-01-19)
Re: non trivial constant folding (2001-01-20)
Re: non trivial constant folding (2001-01-26)
Re: non trivial constant folding (Hans-Bernhard Broeker) (2001-02-01)
| List of all articles for this month |

From: Hans-Bernhard Broeker <>
Newsgroups: comp.compilers
Date: 1 Feb 2001 17:40:23 -0500
Organization: Aachen University of Technology (RWTH)
References: 01-01-015 01-01-022 01-01-033 01-01-090 01-01-108 01-01-129 01-01-151
Keywords: optimize, arithmetic
Posted-Date: 01 Feb 2001 17:40:23 EST

Anton Ertl <> wrote:

> Actually I was thinking more about evaluation order issues; the
> compiler does not need to detect that the program depends on the
> evaluation order in order to produce the same evaluation order for a
> given expression. However, if it wants to optimize by reordering
> the evaluation, and still wants to produce consistent behaviour, it
> probably needs to detect order dependences, and suppress the
> optimization (and issue a warning) if it cannot prove that there are
> no order dependences.

Which it'll practically never be able to do, in the case of floating
point arithmetics. Except for those expressions which can be
evaluated at compile time, already, just about *no* FP computation can
be known to be order-independant, before it's executed. Order
dependence is mainly determined by the actual operands, not by the
structure of the expression.

I.e. unless the compiler does a successful analysis of the "possible"
values of a numerical expression by interval arithmetics or similar
means, it cannot ever know whether it's allowed to optimize evaluation
order or not. In the end, the compiler would effectively be forbidden
to do any such optimization, in any programming language that has
doesn't regard ordering effects as free to decide by the implementor.
Hans-Bernhard Broeker (
Even if all the snow were burnt, ashes would remain.

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.