Re: non trivial constant folding

genew@shuswap.net (Gene Wirchenko)
18 Jan 2001 01:08:46 -0500

          From comp.compilers

Related articles
[12 earlier articles]
Re: non trivial constant folding dew@cray.com (2001-01-09)
Re: non trivial constant folding mpointie@eden-studios.fr (Mickaƫl Pointier) (2001-01-09)
Re: non trivial constant folding morrell@morrell.cup.hp.com (Michael Morrell) (2001-01-09)
Re: non trivial constant folding dmr@bell-labs.com (Dennis Ritchie) (2001-01-11)
Re: non trivial constant folding ONeillCJ@logica.com (Conor O'Neill) (2001-01-11)
Re: non trivial constant folding sjmeyer@www.tdl.com (2001-01-18)
Re: non trivial constant folding genew@shuswap.net (2001-01-18)
Re: non trivial constant folding anton@mips.complang.tuwien.ac.at (2001-01-19)
Re: non trivial constant folding genew@shuswap.net (2001-01-20)
Re: non trivial constant folding anton@mips.complang.tuwien.ac.at (2001-01-26)
Re: non trivial constant folding broeker@physik.rwth-aachen.de (Hans-Bernhard Broeker) (2001-02-01)
| List of all articles for this month |

From: genew@shuswap.net (Gene Wirchenko)
Newsgroups: comp.compilers
Date: 18 Jan 2001 01:08:46 -0500
Organization: Okanagan Internet Junction
References: 01-01-015 01-01-022 01-01-033
Keywords: optimize
Posted-Date: 18 Jan 2001 01:08:45 EST

anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:


> "Mihai Christodorescu" <mihai@cs.wisc.edu> writes:
>> There is also another problem: the optimized expression can behave
>>differently than the original expression, due to operations being executed
>>in different order/with different operands.
>
>If the original program was code with defined behaviour, differences
>in observable behaviour are not optimization, they are an indication
>of a broken compiler.
>
>And even if the original code had undefined behaviour, a particular
>compiler should implement a consistent behaviour for that, if possible
>(for practical reasons, like finding the bug).


          Why? And what behaviour would you suggest? It may not be
possible for the compiler to detect that a given condition can occur.
Consider the possibility of aliasing. Trying to accommodate the
exceptional cases may result in much slower code for the general case.


>> Consider:
>> "MAXINT + x - 1"
>>If x is 1, then evaluating MAXINT + x will overflow.
>>
>>If you optimize the expression to be:
>> "the_value_of_MAXINT_minus_1 + x"
>>(i.e. you evaluate MAXINT - 1 at compile time), then if x is 1, the
>>expression will not overflow.
>
>Well, if your + does exception-on-overflow, or saturating arithmetic,
>then it is not associative, and you cannot apply this transformation.
>
>OTOH, if your + does modulo arithmetic (aka wrap-around), then it is
>associative, and both expressions will give the same result.
>
>So it comes down to: does the operation satisfy the algebraic laws
>required by the transformation? If not, you cannot apply the
>transformation in an optimizer.


          What are the algebraic rules of overflow? Are there any?


Sincerely,


Gene Wirchenko


Post a followup to this message

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