Linus Torvalds's on June 12, 2019 11:09 am: > On Tue, Jun 11, 2019 at 2:55 PM Nicholas Piggin <npiggin@xxxxxxxxx> wrote: >> >> What does this do for performance? I've found this pattern can be >> bad for store aliasing detection. > > I wouldn't expect it to be noticeable, and the lack of argument > reloading etc should make up for it. Plus inlining makes it a > non-issue when that happens. Maybe in isolation. Just seems like a strange pattern to sprinkle around randomly, I wouldn't like it to proliferate. I understand in some cases where a big set of parameters or basically state gets sent around through a lot of interfaces. Within one file to make lines a bit shorter or save a few bytes isn't such a strong case. > > But I guess we could also at least look at using "restrict", if that > ends up helping. Unlike the completely bogus type-based aliasing rules > (that we disable because I think the C people were on some bad bad > drugs when they came up with them), restricted pointers are a real > thing that makes sense. > > That said, we haven't traditionally used it, and I don't know how much > it helps gcc. Maybe gcc ignores it entirely? S Ahh, it's not compiler store alias analysis I'm talking about, but processor (but you raise an interesting point about compiler too, would be nice if we could improve that in general). The processor aliasing problem happens because the struct will be initialised with stores using one base register (e.g., stack register), and then same memory is loaded using a different register (e.g., parameter register). Processor's static heuristics for determining a load doesn't alias with an earlier store doesn't do so well in that case. Just about everywhere I've seen those kind of misspeculation and flushes in the kernel has been this pattern, so I'm wary of it in performance critical code. Thanks, Nick
