Re: non trivial constant folding (Anton Ertl)
19 Jan 2001 23:16:30 -0500

          From comp.compilers

Related articles
[13 earlier articles]
Re: non trivial constant folding (Mickaƫl Pointier) (2001-01-09)
Re: non trivial constant folding (Michael Morrell) (2001-01-09)
Re: non trivial constant folding (Dennis Ritchie) (2001-01-11)
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: (Anton Ertl)
Newsgroups: comp.compilers
Date: 19 Jan 2001 23:16:30 -0500
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
References: 01-01-015 01-01-022 01-01-033 01-01-090
Keywords: optimize, standards
Posted-Date: 19 Jan 2001 23:16:30 EST (Gene Wirchenko) writes:
> (Anton Ertl) wrote:
>>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?

It's hard to find bugs if the behaviour changes when you try to debug
a program.

> And what behaviour would you suggest?

Usually it is best to report an error as soon as possible. In some
cases it is more practical to do what other compilers do. Other than
that, it is pretty arbitrary.

> It may not be
>possible for the compiler to detect that a given condition can occur.

The compiler does not need to detect some condition in order to
produce consistent behaviour.

>Consider the possibility of aliasing. Trying to accommodate the
>exceptional cases may result in much slower code for the general case.

Yes, that's a problem. Then you have to make a decision between code
quality and usability. You can also leave the decision to the user
through different optimization options.

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

The optimization discussed in this thread requires + to be associative
and commutative.

The algebraic laws for + on language "integers" depend on the
language. Many languages do not define the result of an overflow.
Then you as language implementor have the choice:

1) Implement modulo arithmetic and you can use the transformation
while having consistent behaviour.

2) Implement exception-on-overflow, and the program will report the
error ASAP; but if you use the transformation, the behaviour will not
be consistent.

- anton
M. Anton Ertl Some things have to be seen to be believed Most things have to be believed to be seen

Post a followup to this message

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