Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Fri, 06 Sep 2024 07:25:35 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 68
Message-ID: <2024Sep6.092535@mips.complang.tuwien.ac.at>
References: <2024Aug30.161204@mips.complang.tuwien.ac.at> <vat5ap$jthk$2@dont-email.me> <vaunhb$vckc$1@dont-email.me> <vautmu$vr5r$1@dont-email.me> <2024Aug31.170347@mips.complang.tuwien.ac.at> <vavpnh$13tj0$2@dont-email.me> <vb2hir$1ju7q$1@dont-email.me> <8lcadjhnlcj5se1hrmo232viiccjk5alu4@4ax.com> <vb4amr$2rcbt$1@dont-email.me> <2024Sep5.133102@mips.complang.tuwien.ac.at> <vbchiv$cde4$1@dont-email.me> <2024Sep5.174939@mips.complang.tuwien.ac.at> <ljuc4fF86o3U2@mid.individual.net>
Injection-Date: Fri, 06 Sep 2024 10:12:31 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="2e85e44354343afe68fe387c30e9d02d";
	logging-data="805777"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/nUlEyiM/ZCvPMJb3Nfc5o"
Cancel-Lock: sha1:g+ELLbqrAkw7iL7nIwBPHOwEa60=
X-newsreader: xrn 10.11
Bytes: 4270

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>On 2024-09-05 18:49, Anton Ertl wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 05/09/2024 13:31, Anton Ertl wrote:
>
>    [ discussion of the implementation of Gforth as a code-copying
>      and code-pasting interpreter, and the maintenance problems
>      this leads to when changing gcc versions ]
>
>It seems to me that this discussion (of Gforth) has very little do to 
>with the ability of C compilers to optimize away or do something else 
>with C code that the compiler detects invokes Undefined Behavior

Yes.  What I wrote about was just to show what is happening in Gforth,
and that the techniques, even though they may seem totally outlandish
to some, are actually pretty usable across many releases of gcc
(despite the lack of guarantees from gcc); in the last 20 years we
have needed to deal with one new development, and our workaround for
that also works on older gcc releases.

What some C compilers tend to do is, however, better described as
"Assume That Undefined Behaviour Does Not Happen" (ATUBDNH), and
deriving "knowledge" from that (e.g., about the possible values of a
variable), and then using that "knowledge" in "optimizations".

>I don't doubt that Anton has experienced bad effects of the 
>"optimization" of Undefined Behavior, in other contexts

The main bad effect is that I replaced more efficient and shorter code
with less efficient and longer code.  In theory the compiler can
generate the same code for both, but in practice that does not happen.
As an example, the test for the smallest signed integer can be written
with -fwrapv as:

if (x<=x-1)

and gcc -fwrapv compiles this to shorter code on AMD64 than

if (x==CELL_MIN)

What gcc produces for both formulations is longer than

dec %rdi
jno ...

Maybe instead of pursuing "optimizations" against the intentions of
the programmer, they should concentrate on implementing real
optimizations like optimizing either variant into the small code shown
last.

Interestingly, the first idiom is a case where gcc recognizes what the
intention of the programmer is, and warns that it is going to
miscompile it.  The warning is good, the miscompilation not (but it
would be worse without the warning).

In any case, while the actual experience is that I have not been hit
by "optimizations" that ATUBDNH in production code, possibly because I
minimize these assumptions with flags like -fwrapv, the possibility
that my code might be hit by such an "optimization" (e.g., a new one
in a new compiler version, if I am lucky with a new flag for disabling
the assumption, but my source code does not know about it yet) and the
attitude of people who implement such "optimizations" is what I
resent.

- anton
-- 
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
  Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>