Re: Computer architects leaving Intel...

On 05/09/2024 22:05, Bernd Linsel wrote:

On 05.09.24 17:49, Anton Ertl wrote:

>
Nobody said that gcc did anything wrong here.  We were, however,
surprised that -fno-reorder-blocks did not suppress the reordering; we
reported this as bug, but were told that this option does something
different from what it says.  Anyway, we developed a workaround.  And
we also developed a workaround for the code duplication problem that
showed up in gcc-7.
>

 Have you tried interspersing `asm volatile("")` statements?
 It is very often an effective means to prevent gcc from reordering code from before and after the asm statement.
 

(I am quite confident that Anton has uses asm volatile statements like this.)
That only prevents movement of observable behaviour - basically volatile accesses, calls to externally defined functions, and other volatile asm statements.  It does not prevent the movement of any other code.
A commonly used variant is `asm volatile("" ::: "memory")` which is a local memory barrier, and blocks movements of loads and stores.  But that can often be costly in performance, and also does not block movement of code that does not load or store memory.
The compiler is also free to duplicate and shuffle around these "instructions", as long as they are "executed" as required.  So it can do the same kinds of movements as it did before, transforming freely between:
A:
asm volatile("");
doThis();
asm volatile("");
B:
asm volatile("");
doThat();
asm volatile("");
C:
and
A:
asm volatile("");
doThis();
asm volatile("");
asm volatile("");
doThat();
asm volatile("");
goto C
B:
asm volatile("");
doThat();
asm volatile("");
C:

If you additional specify inputs, e.g. `asm volatile("" :: "r" (foo))`, you can force gcc to keep `foo` alive up to this point.
 

That is sometimes a useful form of code.  I've used it in sequences like this:
x = long_calculation()_;
asm volatile ("" :: "g" (x));
get_lock();
use_x(x);
release_lock();
Without that block, the compiler is free to move long_calculation() inside the locked area (within limitations from its knowledge of observable behaviour).  In most practical cases, the get_lock() and release_lock() parts will have a memory barrier, and you don't actually get much of long_calculation() that might be moved, but it is certainly a possibility.
asm volatile("" : "+g" (x));
can also be useful.  It not only forces "x" to be stable before the statement is "executed", but it tells the compiler to forget all it knows about after it.