Re: Optimization techniques

On 01/05/2019 03:24, Gene Wirchenko wrote:
> On Sun, 28 Apr 2019 23:49:53 +0200, David Brown
> <david.brown@hesbynett.no> wrote:
>
> [snip]
>
>> If you are writing your code in a "C with the extra feature of having
>> defined behaviour on signed integer overflow", and only compile it with
>> suitable compilers (or compiler flags), then that's okay. But don't
>> call it correct C code and blame compilers for your own mistakes or
>> unwarranted assumptions.
>
> I would like to see it as part of the language. I *know* that I
> want to have an error be thrown at run-time if an error can be
> detected. (It is not an unwarranted assumption.) It is not as if
> detecting signed integer overflow is a difficult thing on, for
> example, System/370, which also dates from 1970.


Detecting signed overflow at run-time can be a significant cost. It
ruins expression manipulation, optimisation, and simplification - much
more than making signed overflow be two's complement. Even compared to
a dumb translation compilation of expressions, it nearly doubles the
size of the code on many processors as you have to follow each
arithmetic instruction with a "jump if overflow". (Some cpus have
"trapping" arithmetic instructions, but certainly not all.) On small
processors, this is all a heavy penalty on performance. On big
processors, simple instructions are often "free" while the cpu is
waiting for memory reads, but these sequences thrash your branch
prediction buffers.


No, throwing an error on overflows is not hard - but it /is/ costly. It
can be a marvellous tool during testing and debugging, and may be worth
leaving active in some programs, but it has a price.


However, if by "part of the language" you are thinking more of optional
or configurable possibilities - perhaps like the standard pragmas for
controlling some floating point details, then I like that idea.
Standard pragmas letting people choose signed overflow behaviour, from
the default of "undefined behaviour" to trapping/signalling, two's
complement wrapping, and perhaps saturation, would be nice.


>
> I am fine with compiler options allowing each of us to have our
> respective ways. I am tired of the default being "Overflow happens;
> too bad". That is why I refuse to use C. It is too dangerous for my
> taste.
>


Choice is a great thing. I don't use C on PC's - not because it is
dangerous as such, but because it takes too much effort to use it safely
and well. But I use it on small microcontrollers, where I am willing to
put in the effort to make the code correct and efficient. On PC's, I
mostly use Python - then I don't have to concern myself about overflows
(or many other details that the language handles), and I am willing to
pay the efficiency price involved.

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