Linux and aliasing?

Ross Harvey ross@ghs.com
Sun Jun 6 15:08:00 GMT 1999


> From: Linus Torvalds <torvalds@transmeta.com>
>
> On Sun, 6 Jun 1999 mark@codesourcery.com wrote:
> > 
> > Right.  But the part that's causing aliasing issues is just a memcpy;
> > that's the `*(u32 *) p' bit.   You could write:
> > 
> >   memcpy (&a, p, sizeof (a));
> >   a = ntohl (a);
>
> Which is crap.
>
> And a compiler that requires you to write code like that is, by
> implication..
>:::
> If you can't see why
>
> 	a = ntohl((u32 *) p);
>
> is better than the horrible thing you're suggesting (regardless of whether
> the code generated is the same or not), then I might as well throw in the
> towel immediately. The whole point of my suggestion was to make good code
> generation possible with an interface that you can actually use without
> barfing..
>
> 		Linus

Umm, the ice is getting thin, here. From time to time, I have to change
kernel code FROM things like ``a = ntohl((u32 *) p);'' TO things like
``memcpy (&a, p, sizeof a);  a = ntohl (a);''.

Why? Because it's illegal for a reason, and the alpha platform I support
has alignment requirements for which I have a guarantee that the memcpy
approach will work and be reasonably efficient. The cast can generate a
kernel alignment fault and will either panic or have a hideous run-time
fixup cost.  I know we are talking about aliasing, but in terms of why the
rules are there, I think this is an illuminating example.

LP64 is coming to the PeeCee world, and even if the fixup is in hardware,
you still have a runtime penalty for making addressibility assumptions that
are properly the domain of the compiler.

	Ross.Harvey@Computer.Org


More information about the Gcc mailing list