Re: Computer architects leaving Intel...

On Fri, 06 Sep 2024 07:25:35 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:

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

Good trick.
The same trick in non-destructive form would be 1 byte longer.
 cmp $1, %rdi
 jno ...

But I was not able to force any of compilers currently installed on my
home desktop (gcc 13.2, clang 18.1, MSVC 19.30.30706 == VS2022) to
produce such code.

The closest was MSVC that sometimes (not in all circumstances) produces
2 bytes longer versiin:
  49 8d 49 ff             lea    -0x1(%r9),%rcx
  4c 3b c9                cmp    %rcx,%r9

Of course, it's still good deal shorter than
  48 ba 00 00 00 00 00 00 00 80  movabs $0x8000000000000000,%rdx
  4c 3b ca                       cmp    %rdx,%r9

Both gcc and clang [under -fwrapv] insisted on turning x<=x-1 into
x==LLONG_MIN.

However even if we were able to force compiler to produce desired code,
the space saving is architecture-specific.
E.g. I expect no saving on ARM64 where both variants occupie 8 bytes.

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

You had more luck with warnings than I did.
In all my test cases both gcc and clang [in absence of -fwrapv]
silently dropped the check and depended code.
MSVC didn't drop it, so, naturally, also it produced no 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