Path: csiph.com!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: Kaz Kylheku <847-115-0292@kylheku.com> Newsgroups: comp.compilers Subject: Re: Optimization techniques Date: Thu, 2 May 2019 17:40:13 +0000 (UTC) Organization: Aioe.org NNTP Server Lines: 63 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <19-05-011@comp.compilers> References: <72d208c9-169f-155c-5e73-9ca74f78e390@gkc.org.uk> <19-04-021@comp.compilers> <19-04-023@comp.compilers> <19-04-037@comp.compilers> <19-04-052@comp.compilers> <19-05-002@comp.compilers> Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="95431"; mail-complaints-to="abuse@iecc.com" Keywords: optimize, arithmetic, errors, comment Posted-Date: 02 May 2019 14:16:53 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:2247 On 2019-05-01, David Brown wrote: > 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 If we detect signed overflow and treat it as an error condition, then we can optimize algebraically just as before, on the assumption that overflow doesn't happen. If it does happen, we have a predictable handling, rather than "undefined behavior". We just don't constrain the exact situations when it must happen. I.e. as usual, optimizations are permitted that can eliminate instances of overflow that would otherwise happen if the specified arithmetic is followed, optimizations that can introduce overflow aren't allowed. > 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 can also set a processor flag which can be tested after a batch of operations, rather than each one. That is reasonably cheap on those processors because the flag is there anyway; you just have to peek at it once in a while. Some RISCs can write overflow info into an additional output register, rather than a global flag word, IIRC. We often care about whether anything at all overflowed in a complex expression, without caring about which specific operation on which operands. The design issue then is how to indicate the granularity of overflow detection in the higher level language. A scoped construct suggests itself, the "owfl" operator: owfl(expr, alt) If anything inside expr overflows, then alt is evaluated, and taken as the result of the expression. Considerations have to be given to how this nests with itself, including through functions, and when/how does the overflow condition get cleared. (We don't want it so that once an overflow happens, every owfl subsequently executed defaults to its alt until the program terminates.) [FWIW the x86 series had an INTO instruction which interrupts if the overflow flag is on, but they took it out of 64 bit mode. You can still do a conditional jump or move. -John]