> The problem with 'restrict' is that almost nobody uses it, and it does Also gcc traditionally didn't do a very good job using it (this might be better in the very latest versions). At least some of the 3.x often discarded this information. > automatically. But it should work well as a way to get Fortran-like > performance from HPC workloads written in C - which is where most of the > people are who really want the alias analysis. It's more than just HPC -- a lot of code has critical loops. > > it seems like a nice opt-in thing that can be used where the aliases are > > verified and the code is particularly performance critical... > > Yes. I think we could use it in the kernel, although I'm not sure how many > cases we would ever find where we really care. Very little I suspect. Also the optimizations that gcc does with this often increase the code size. While that can be a win, with people judging gcc's output apparently *ONLY* on the code size as seen in this thread[1] it would obviously not compete well. -Andi [1] although there are compilers around that generate smaller code than gcc at its best. -- ak@xxxxxxxxxxxxxxx -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html