Re: Optimization techniques

"Robin Vowels" <>
Tue, 7 May 2019 01:42:36 +1000

          From comp.compilers

Related articles
[32 earlier articles]
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 (Robin Vowels) (2019-05-07)
Re: Optimization techniques (David Brown) (2019-05-07)
| List of all articles for this month |

From: "Robin Vowels" <>
Newsgroups: comp.compilers
Date: Tue, 7 May 2019 01:42:36 +1000
Organization: Compilers Central
References: <> 19-04-021 19-04-023 19-04-037 19-04-052 19-05-002
Injection-Info:; posting-host=""; logging-data="85130"; mail-complaints-to=""
Keywords: errors, comment
Posted-Date: 06 May 2019 13:48:17 EDT

From: "David Brown" <>
> On 01/05/2019 03:24, Gene Wirchenko wrote:
>> On Sun, 28 Apr 2019 23:49:53 +0200, David Brown
>> <> wrote:

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

Signed (and unsigned) overflow was around on the IBM 360
from 1965.

> Detecting signed overflow at run-time can be a significant cost.

Usually not. Even on humble micros, a Junp on overflow or
an Interrupt on overflow is usually available.

On the S/370 that was mentioned above, and the S/360 before it,
and later machines in that family, an overflow is detected by
hardware. Extra instructions are not required to detect the overflow.
(They can be, if the user desires to process them him/herself.)

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

A jump on overflow is usually a short instruction, less than
the length of instruction(s) that generated the 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.

Again, on the S/370 et al already mentioned, no extra instrucions
are required to test for overflow.

Branch prediction is irrelevant in the event of an overflow.
To proceed with the computation is pointless.

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

The "price" of leaving in checks (active or otherwise) is small
compared to the human time wasted in tracking down a bug in a program --
whether it is overflow or some other computational error.
[IBM mainframes have integer overflow traps, but the Intel micros that
most of use do not. There's an overflow flag but the only way to act
on it is to put a conditional branch after each instruction that might
overflow, which could make things a tad bulky and sluggish. Maybe
that's worth it, but it's far from cheap. -John]

Post a followup to this message

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