From mboxrd@z Thu Jan 1 00:00:00 1970 From: mark@codesourcery.com To: davem@redhat.com Cc: toon@moene.indiv.nluug.nl, ak@muc.de, law@cygnus.com, jbuck@Synopsys.COM, torvalds@transmeta.com, craig@jcb-sc.com, chip@perlsupport.com, egcs@egcs.cygnus.com Subject: Re: Linux and aliasing? Date: Wed, 30 Jun 1999 15:43:00 -0000 Message-ID: <19990605165443C.mitchell@codesourcery.com> References: <199906051803.LAA15436@pizda.davem.net> <37597443.CCD4578A@moene.indiv.nluug.nl> <199906051925.MAA15498@pizda.davem.net> X-SW-Source: 1999-06n/msg00210.html Message-ID: <19990630154300.ZAWJLNZ7W1bNMBg0c1_KJ_sNMtk-SAUmTi3ykOjr2kw@z> >>>>> "David" == David S Miller writes: David> So the situation here is quite the contrary to the David> assertion, one of the most worrysome areas of the kernel, David> with respect to the union'ization of data structures to David> remove non-alias-friendly casts, is also the place where David> alias analysis would be highly beneficial. Note, however, that placing *anything* in alias set zero tends to largely botch type-based alias analysis. Since alias set zero means that anything can be changed, no code on a path after the alias set zero access can use typed-based alias analysis from before that point. So, even with Linus' proposal, or my less intrusive proposal, this code may not benefit that greatly. As I pointed out before, you can introduce unions. You will then get compile-time errors. You can then run through and fix them all. This will be tedious. Yes, it will be a large patch, but not a complex one. Do one data structure at a time to make it simpler. Such a patch may not be appropriate for the stable kernels, but it should be tolerable on the unstable kernels. I fail to see what is so *hard* about this; I do see that it will take effort. Your argument about user-space headers is valid. However, you can always do: /* user-space header */ struct s { int i; int j; }; /* But sometimes really the whole thing is a double. */ /* kernel header */ union ks { struct s s; double d; }; That doesn't require changing the user-space headers. Yes, you introduce some duplication. That's the price of not writing ANSI/ISO C from the standard *and* wanting type-based alias analysis to work correctly *and* wanting to keep user-space headers intact. Quite frankly, I still don't fully buy the "it's too hard to fix, but where it's too hard is exactly where we need it" conundrum. There are a variety of things you can do: unions, macros to access the fields by a type-safe means, memcpy and friends (see my earlier post for why this should be fast), etc. I believe you that it's a pain in the neck to fix this stuff; just not that it's simultaneously as hard *and* as important as you claim. If there are really hot spots in the kernel that need to go fast, you can hand-code them in assembly, or rewrite them in portable C. Yes, that will be a pain. The benefits may or may not outweigh the cost. That's a decision you have to make. But, it's not clear that introducing some extension, perhaps with gotchas we cannot forsee, to GCC will have more benefits than costs, either. In some sense, Linux is coded in a dialect of C. In this dialect, you can do funny casts and things still work. That's not ANSI/ISO C, and it's not something that GNU CC ever promised to support (unlike extended asms, for example.) But, the "Linux dialect" *is* still supported with -fstrict-aliasing. You want the new optimization, but to retain the old dialect. In short, you want to have your cake and eat it too. That's natural, but not necessarily reasonable or realistic. If someone contributes a patch that: o Provides some "anti-aliasing" :-) behavior for non-conforming programs in a well thought-out way. o Does not affect conforming programs. o Is easy to maintain. See my earlier post for some of the problems that must be solved. o Looks to be useful to projects outside of the Linux kernel. then, I would expect that the GCC maintainers would react favorably. But, frankly, I bet there are a lot of projects on which we could spend our time that would have more widespread benefits, for GCC, the kernel, and the community. For example, better x86 scheduling would allow *all* applications, probably including Linux, to run significantly faster. I am just not persuaded that this is a good place to spend my time, espcially what little I can afford to volunteer for free. I am not persuaded that it is a good use of anyone else's time, either, including yours, David, or you Andi. You are excellent programmers, and your contributions to many projects are valuable; I bet this isn't the most useful thing you could do. Unfortunately, (or perhaps fortunately for the readers of this list!), I can't afford to spend any more time arguing the point. I hope that doesn't offend anyone. I do understand the Linux issues, and why you're arguing for what you're arguing for. Let's agree to disagree, at least until someone produces a patch for GCC that we can start a fresh argument about. :-) -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com