Linux and aliasing?

[mark@codesourcery.com]

>>>>> "David" == David S Miller <davem@redhat.com> 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