2024年9月28日 23:55,Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx> wrote:
On 2024-09-28 17:49, Alan Stern wrote:
On Sat, Sep 28, 2024 at 11:32:18AM -0400, Mathieu Desnoyers wrote:
On 2024-09-28 16:49, Alan Stern wrote:I thought you were trying to prevent the compiler from using one pointer
On Sat, Sep 28, 2024 at 09:51:27AM -0400, Mathieu Desnoyers wrote:
equality, which does not preserve address dependencies and allows the
following misordering speculations:
- If @b is a constant, the compiler can issue the loads which depend
on @a before loading @a.
- If @b is a register populated by a prior load, weakly-ordered
CPUs can speculate loads which depend on @a before loading @a.
It shouldn't matter whether @a and @b are constants, registers, or
anything else. All that matters is that the compiler uses the wrong
one, which allows weakly ordered CPUs to speculate loads you wouldn't
expect it to, based on the source code alone.
I only partially agree here.
On weakly-ordered architectures, indeed we don't care whether the
issue is caused by the compiler reordering the code (constant)
or the CPU speculating the load (registers).
However, on strongly-ordered architectures, AFAIU, only the constant
case is problematic (compiler reordering the dependent load), because
instead of the other, not trying to prevent it from reordering anything.
Isn't this the point the documentation wants to get across when it says
that comparing pointers can be dangerous?
The motivation for introducing ptr_eq() is indeed because the
compiler barrier is not sufficient to prevent the compiler from
using one pointer instead of the other.
barrier_data(&b) prevents that.