Re: Optimization techniques and undefined behavior

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?


> Algebraic reductions that can change the result can be confined
> to evaluation regions similar to (perhaps tied to) sequence points,
> such that if we write:
>
> int y = x * 2;
> int z = y / 2;
>
> then the calculations are belabored; z is not reduced to x.
>


Note that in C, as defined by the standards (whether you agree with them
or not), sequence points do not cause any such effects. z can be
reduced to x.


> Anyway, anyone who wants "x * 2 / 2" to be reduced to "x" through layers
> of macrology can always use a more sophisticated macro processor. Parse
> it, build a tree, and do the optimization in the preprocessor.
>


I find the C preprocessor to be quite sophisticated. And I find
compiler optimisation, such as inline and constant propagation, to be
even more sophisticated. Sometimes I use additional pre-processing or
code generation for specialist use, but I am happy not to need it for
this kind of thing.


> C should serve as a stable "higher level assembly" target for that sort
> of thing.


No, C should serve as a stable "higher level language" - not an
assembly. If you want to have a "higher level assembly", then you can
make that from C - typically the usage of unsigned types rather than
signed types will give you most of what you want here. A liberal
sprinkling of "volatile" is also useful in such use-cases. And, if you
really want to, it's not hard to write something like:


#ifdef __GNUC__
#pragma GCC optimize -fwrapv
#endif

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