Re: non trivial constant folding

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


> genew@shuswap.net (Gene Wirchenko) writes:
>>anton@mips.complang.tuwien.ac.at (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.


          Could be. It's more likely that the undefined behaviour will be
consistently a certain way on a given system. On a different system,
the undefined behaviour might be different.


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


          Huh? How do you propose to, for example, handle overflow if it
can't be detected?


          What if the condition can only be caught some of the time? You
still have the problem.


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


          The quality may be just fine. It might be impossible for a
certain exception to be thrown, but the compiler puts in handling code
anyway. Slower code and the loss in speed doesn't buy anything.


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


          You're going to hate floating point.


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


          Or do what Microsoft did in MBASIC 5 (changing the behaviour from
the previous throwing of an error): print a warning message and
continue. (There was no way for the program to catch the error.) I
thought this definitely was a Dumb Move.


Sincerely,


Gene Wirchenko

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