Re: Optimization techniques

David Brown <>
Wed, 1 May 2019 09:20:23 +0200

          From comp.compilers

Related articles
[28 earlier articles]
Re: Optimization techniques (David Brown) (2019-04-28)
Re: Optimization techniques (David Brown) (2019-04-28)
Re: Optimization techniques (Gene Wirchenko) (2019-04-30)
Re: Optimization techniques (Gene Wirchenko) (2019-04-30)
Re: Optimization techniques (Gene Wirchenko) (2019-04-30)
Re: Optimization techniques (David Brown) (2019-05-01)
Re: Optimization techniques (David Brown) (2019-05-01)
Re: Optimization techniques (Martin Ward) (2019-05-02)
Re: Optimization techniques (Kaz Kylheku) (2019-05-02)
Re: Optimization techniques (Kaz Kylheku) (2019-05-02)
Re: Optimization techniques and error detection (Gene Wirchenko) (2019-05-03)
Re: Optimization techniques (Robin Vowels) (2019-05-07)
Re: Optimization techniques (David Brown) (2019-05-07)
| List of all articles for this month |

From: David Brown <>
Newsgroups: comp.compilers
Date: Wed, 1 May 2019 09:20:23 +0200
Organization: A noiseless patient Spider
References: <> 19-04-021 19-04-023 19-04-037 19-04-052
Injection-Info:; posting-host=""; logging-data="53721"; mail-complaints-to=""
Keywords: standards, arithmetic
Posted-Date: 01 May 2019 21:31:32 EDT
Content-Language: en-GB

On 01/05/2019 03:24, Gene Wirchenko wrote:
> On Sun, 28 Apr 2019 23:49:53 +0200, David Brown
> <> 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.

Post a followup to this message

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