On Wed, Jun 08, 2022 at 11:00:46AM +0900, Akira Yokosawa wrote: > On Tue, 7 Jun 2022 10:34:08 -0400, Alan Stern wrote: > > On Tue, Jun 07, 2022 at 02:34:33PM +0100, Will Deacon wrote: > >> Alternatively, maybe we should be removing the historical stuff from the > >> document altogether if it's no longer needed. We don't have any occurrences > >> of read_barrier_depends() anymore, so why confuse people with it? > > > > How about relegating discussion of these barriers to a special > > "historical" or "niche architecture" section of the document? In a > > separate patch, of course. > > Another option would be to add a section on "Ordering guarantees by > dependencies", and explain three variants: address, data, and > control. We have only "control dependencies" section at the moment > and uses "data dependency" without properly defining it. > > Address dependencies are special in that they can provide load-to-load > ordering guarantees as well as those of load-to-store. > Alpha doesn't provide these guarantees at the architecture level, hence > the implicit address-dependency barrier in READ_ONCE(). > > Also, IIUC, arm64's READ_ONCE() is promoted to acquire-load when > LTO is enabled. It is to cope with the possible (but not observed > yet) transformation of address dependencies into control dependencies, > which can't provide load-to-load ordering guarantees. > > These points can be added later in memory-barriers.txt, but I'm > afraid I might not be up to such involved changes. I think we should try hard to avoid documenting how specific architectures implement the memory model (in this document, at least); it's likely to stagnate and it encourages people to rely on the behaviours of a specific architecture rather than the portable guarantees offered by the higher-level memory model. Will
