Re: Optimization techniques and undefined behavior

On 03/05/2019 13:29, Andy Walker wrote:
> On 03/05/2019 00:48, Bart wrote:
>>>> If you have two unknown values A and B, and need to multiply, you won't
>>>> know if the result will overflow.
>>>   int A := ..., B := ...;
>>>   int C := ( A = 0 | 0 |: abs B <= maxint % abs A | A*B | error
>>> (...); 0 );
>> That sounds unmanageable
>
>     Indeed, but it was a proof of concept.  Obviously, you can tuck
> that line away either using a macro definition or as a function/operator.
>
>>                (think about checks here: a*a+b*(c*d), and how
>> you might proceed from the error if not aborting) and inefficient if one
>> multiply turns into half a dozen operations including a divide.
>
>     How quickly do you want your buggy results?  If you have to write
> code to check, then it takes time, both to write and to execute.  Yes, if
> you have a complicated expression, it takes lots of time to execute, and
> your program will run much more slowly.


I just haven't found overflow on numbers the huge problem that people
say it is.


I've spent 10 minutes adding overflow checks (for + - * ops on signed
int64) on my latest compiler, and tested a range of applications.


Nothing triggered it, except a tiny part of a compiler (some code which
had to convert "18446744073709551615" into 64-bit binary), and there it
was just because some mixed arithmetic was done as signed rather than
signed. In my language, that shouldn't matter, not in that case. And
that would have been something that was well tested.


The upshot is that no overflows due to logic error were discovered in my
brief tests. But you can also see how easy it can be to add such checks.
(Although reporting the error location in the program source is a lot
harder.)


>> If such overflow checks need to be routinely done, then it really needs
>> language support.
>
>     If you want to regain efficiency, then it needs not language so
> much as hardware support.


The overflow check I did above is just one x64 instruction (jo <addr>)
after each add, sub or mul. Is that the sort of hardware support you mean?


>     You're too young.  C on a PDP-11/34 running Unix, in the mid-70s,
> was roughly the 10th serious language and the 5th computer/OS I used over
> 16 years or so, and the first that did not have array-bound checks and
> overflow checks compiled in and switched on by default.


(I did use the pdp11/34 actually, running Fortran on rsx11m. I have no
idea whether that had any such checks. But at least Fortran makes it
feasible with well-defined arrays and well-defined array bounds.
[I'm pretty sure it didn't. -John]


C is just a mess; it has arrays of sorts, but people generally use raw
pointers without associated bounds. Maybe that's one reason why your C
didn't have it. Or did it somehow manage it if enabled?)


>> During development, yes, but perhaps not after a program is supposed to
>> be working.
>
>     Dijkstra[?] wrote along the lines of "It's like wearing water
> wings to paddle around the swimming pool and discarding them when you
> swim out to sea".


Swimming out to sea would be foolhardy even wearing a buoyancy aid.

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