Re: Optimization techniques

From: "David Brown" <david.brown@hesbynett.no>
> 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:


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

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