> The point is that the compiler is then free to do it. If things > slow down after the compiler gets *more* information, then that > is a problem with the compiler heuristics rather than the > information we give it.
The point was the -Os disables it typically then. (not always, compiler heuristics are far from perfect) > > > > Then x86s tend to have very very fast L1 caches and > > if something is not in L1 on reads then the cost of fetching > > something for a read dwarfs the few cycles you can typically > > get out of this. > > Well most architectures have L1 caches of several cycles. And > L2 miss typically means going to L2 which in some cases the > compiler is expected to attempt to cover as much as possible > (eg in-order architectures). L2 cache is so much slower that scheduling a few instructions more doesn't help much. > stall, so you still want to get loads out early if possible. > > Even a lot of OOOE CPUs I think won't have the best alias > anaysis, so all else being equal, it wouldn't hurt them to > move loads earlier. Hmm, but if the load is nearby it won't matter if a store is in the middle, because the CPU will just execute over it. The real big win is if you do some computation inbetween, but at least for typical list manipulation there isn't really any. > > Also at least x86 gcc normally doesn't do scheduling > > beyond basic blocks, so any if () shuts it up. > > I don't think any of this is a reason not to use restrict, though. > But... there are so many places we could add it to the kernel, and > probably so few where it makes much difference. Maybe it should be > able to help some critical core code, though. Frankly I think it would be another unlikely(). -Andi -- a...@linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
