Linux and aliasing?

Andi Kleen ak@muc.de
Wed Jun 30 15:43:00 GMT 1999


On Sat, Jun 05, 1999 at 07:41:07PM +0200, mark@codesourcery.com wrote:
> >>>>> "Andi" == Andi Kleen <ak@muc.de> writes:
> 
>     Andi> Mark, even when you don't like it, would you as
>     Andi> alias-expert-in-residence think that the basic strategy is
>     Andi> workable?
> 
> I don't know what workable means.  
> 
> But, I would argue against your patch.  There are cases where a
> pointer is cast to one type, and then cast back to another, and then
> used.  These cases are conforming, and I think that Linus' proposal
> will disable alias analysis in these cases.  That's bad.  Especially
> since often these casts are to `void*' for the express purpose in
> storing them in some kind of generic data structure.

I agree.

> 
> Note that I made an alternate, more circumspect, proposal, which has
> been ignored by both Linus and yourelf up until now, although there's
> been so much traffic that one couldn't really expect anyone to keep up
> with all of it:

Sorry, I must have missed it.

> 
>   Put expressions of the form `*((foo*) (&x))' in alias set zero if
>   x does not have type foo, or one of the types that is allowed
>   to alias it.
> 
> This proposal only affects nonconforming code, and thus changing the
> behavior of the compiler will not pessimize any conforming code.  It
> is important that `x' be a variable, or a field of a variable, not an
> arbitrary expression.  (For example, I don't think this should apply
> to `*((foo*) (f()))' since that might be conforming.)  But, if
> `x' is a variable, or of the form `x->y' or `x.'y' then we should be
> OK (it's not legal to talk about `x->y' if `x' is not of the right
> type), then we should be OK.

The "only with variable rule" makes it a bit more complicated and arbitary
than I hoped (e.g. I don't see
the difference between *((foo*)f()) = 1; and { foo *x=(foo*)f(); *x=1 }), 
but I could live with that if it is needed for the compromise needed for a
consensus. 

I think the kernel has some of the first cases, so it may be helpful to have
an optional (=not in -Wall) warning at least for the function case so that 
someone could go through the code base and fix it.


> So, this proposal is, IMO, a workable extension of the standard
> semantics.  I don't know if this covers all the cases in the kernel,
> but it should be easier to change Linux to fit this model than the
> strictly conforming one.
> 
> I'm also not sure if this is a good idea.  If we don't document this
> behavior, we're not promising it to Linux.  So, we might break it
> later.  If we *do* document it, then we have to promise to maintain
> this behavior.  That's extra work for us; we have to be convinced
> there's a good enough reason, and I'm not convinced yet.  The
> questions are:
> 
>   o How badly does Linux need the extra cycles that might be squeezed
>     out by this extra alias analysis?  How much faster will the 
>     average Linux system go?

There are some hot paths (e.g. TCP input packet processing) that would
benefit from it. The average Linux box is a work station that is mostly
idle (:@), but for high load servers and applications like Beowulf clusters
where latency counts it is helpful. Also  I think it will be more important
in the future (e.g. on Linux/IA64), where the CPU needs much more compiler
support for good performance.
> 
>   o How hard would it be to fix the kernel?

Very hard. I just tried to fix it in a small part of the TCP code, and it
already involved major changes. The main problem is that these generally
cannot be encapsulated in modules, it has to be changed globally, which
can be a big problem in a system with lots of external code and complicated
dependencies like Linux.


> So, in summary, I think:
> 
>   o It's not clear we want this behavior that badly.
>   o A correct implementation will be difficult.
>   o There will be maintenance headaches.
> 
> Furthermoe, I bet that by now, if all this energy had been spent
> fixing the code in the kernel, you'd have made good headway on some of
> the most prominent data structures.  Yes, this will be a tedious
> chore, but it's an easy one: you enclose things in a union, compile,
> see what doesn't, fix it, and go on.  

Erm no, it isn't that easy. There are no warnings and these cast could hide
everywhere. Someone would basically have to carefully audit about 3.5M LOCs of 
kernel source. And you probably know hard it is to coordinate such mega
patches with multiple (in case of Linux hundreds) maintainers. e.g. I already 
had to discard the nowhere near complete TCP alias fix work from my working
tree again, because David would most likely not have accepted it at this 
point because of the major changes involved, and keep it would have required
substantial continuous effort to hand integrate most new patches because
of the rejects.  Doing it in a crash effort is logistically not possible
I think.  The only way to do it are continuous slow incremental changes,
and the proposed gcc extension would make it a lot easier I think.



-Andi
-- 
This is like TV. I don't like TV.



More information about the Gcc mailing list