On Sun, 21 Oct 2007 16:02:15 -0700 (PDT) David Miller <[EMAIL PROTECTED]> wrote:
> From: Pierre Ossman <[EMAIL PROTECTED]> > Date: Sun, 21 Oct 2007 23:21:13 +0200 > > > Not sure that would be valid. memcpy() is defined as having void* > > arguments, and the compiler cannot just ignore that if it chooses to > > inline it. > > Yes it can, there are C language rules about the alignment of types > that the compiler completely can take advantage of in those kinds of > situations. > I'm not debating that. What I'm saying is that calling memcpy() casts your pointers to void* with the included semantical changes. It can't just ignore that because it decides to inline the function. It would be the same thing as when gcc decided to ignore the volatile qualifier on a pointer just because it could optimize away to the real object and discover it wasn't marked with volatile. Something that was considered a bug and was fixed. > If you don't believe me, compile something like the following > with optimizations enabled: gcc has had bugs in the past. > You will get a 64-bit load and a 64-bit store emitted by > the compiler. Here is what we get on sparc64: > I assume those ops cause a bus error on unaligned addresses? > > However, instead of relying upon magic like this, let's just tell the > compiler explicitly what it going on by using get_unaligned(). > It wouldn't be magic: memcpy(&icmp_param.data.icmph, skb_transport_header(skb), sizeof(struct icmphdr)); I believe platforms without alignment requirements could optimize this better than the series of assignments. Not that I think this will be a potential bottle neck, but still. > Next, there are redundant stores being done here since the code and > type are explicitly overwritten in various ways. Indeed. Rgds Pierre
signature.asc
Description: PGP signature
