Re: Optimization techniques and undefined behavior

On 2019-04-28, David Brown <david.brown@hesbynett.no> wrote:
> On 26/04/2019 04:26, Kaz Kylheku wrote:
>> On 2019-04-25, David Brown <david.brown@hesbynett.no> wrote:
>>> It knows that "x * 2 / 2" is "x". It knows that "x + 1 > x" is true.
>>
>> Also, we could have it so that multiplication wraps, and yet in the same
>> breath allow algebraic reductions like this anyway.
>>
>> Basically it can be so that, if overflow takes place in the abstract
>> semantics of "x * 2 / 2", the result can be either the truncated
>> version, or just x, if the algebraic reduction took place.
>>
>
> I am afraid I don't understand you here. Are you saying that you could
> define the language's arithmetic so that, given "x * 2 / 2", the
> compiler could return /either/ "x" or the result you would get from
> wrapped overflow calculations? You are defining two possible "correct"
> answers?


I'm fairly comfortable with this, because it maps to the familiar ISO C
concept of "unspecified behavior".


For instance, this program can produce one of the results -12, -6, -2
or 4, based on which of the six permutations over the order in which the
three functions are called.


    #include <stdio.h>


    int x = 1;


    int add2(void)
    {
        x += 2;
        return 0;
    }


    int mul4(void)
    {
        x *= 4;
        return 0;
    }


    int neg(void)
    {
        x = -x;
        return 0;
    }


    void dummy(int a, int b, int c)
    {
    }


    int main()
    {
        dummy(add2(), mul4(), neg());
        printf("%d\n", x);
    }


Unspecified behavior isn't exactly wonderful, but it's better than
undefined behavior.

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