On Thu, Feb 20, 2014 at 09:34:57AM -0800, Linus Torvalds wrote: > On Thu, Feb 20, 2014 at 9:14 AM, Torvald Riegel <trie...@redhat.com> wrote: > >> > >> So the clarification is basically to the statement that the "if > >> (consume(p)) a" version *would* have an ordering guarantee between the > >> read of "p" and "a", but the "consume(p) ? a : b" would *not* have > >> such an ordering guarantee. Yes? > > > > Not as I understand it. If my reply above wasn't clear, let me know and > > I'll try to rephrase it into something that is. > > Yeah, so you and Paul agree. And as I mentioned in the email that > crossed with yours, I think that means that the standard is overly > complex, hard to understand, fragile, and all *pointlessly* so. > > Btw, there are many ways that "use a consume as an input to a > conditional" can happen. In particular, even if the result is actually > *used* like a pointer as far as the programmer is concerned, tricks > like pointer compression etc can well mean that the "pointer" is > actually at least partly implemented using conditionals, so that some > paths end up being only dependent through a comparison of the pointer > value. > > So I very much did *not* want to complicate the "litmus test" code > snippet when Paul tried to make it more complex, but I do think that > there are cases where code that "looks" like pure pointer chasing > actually is not for some cases, and then can become basically that > litmus test for some path. > > Just to give you an example: in simple list handling it is not at all > unusual to have a special node that is discovered by comparing the > address, not by just loading from the pointer and following the list > itself. Examples of that would be a HEAD node in a doubly linked list > (Linux uses this concept quite widely, it's our default list > implementation), or it could be a place-marker ("cursor" entry) in the > list for safe traversal in the presence of concurrent deletes etc.
Yep, good example. And also an example where the comparison does not need to create any particular ordering. > And obviously there is the already much earlier mentioned > compiler-induced compare, due to value speculation, that can basically > create such sequences even wherethey did not originally exist in the > source code itself. > > So even if you work with "pointer dereferences", and thus match that > particular consume pattern, I really don't see why anybody would think > that "hey, we can ignore any control dependencies" is a good idea. > It's a *TERRIBLE* idea. > > And as mentioned, it's a terrible idea with no upsides. It doesn't > help compiler optimizations for the case it's *intended* to help, > since those optimizations can still be done without the horribly > broken semantics. It doesn't help compiler writers, it just confuses > them. > > And it sure as hell doesn't help users. Yep. And in 2014 we know a lot more about the hardware, so could make a reasonable proposal. In contrast, back in 2007 and 2008 memory ordering was much more of a dark art, and proposals for control dependencies therefore didn't get very far. Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/