Hi, This is an interesting thread. I think it is very common that people try to avoid making a copy from the buffer filled by recv() (or alike) to achieve lowest latency. Given that 1. The "union trick" has always worked with GCC, and is now hallowed by the standard. So it sounds like GCC might change in the future. 2. Somewhere in the code that might manipulate the buffer via somehow casted packed C struct. Hence, any compiler is unlikely able to avoid making call if memcpy() is used. Then, I have the following questions: A. I use GCC and portability isn't an issue. What is the best type punning method to achieve lowest latency? B. Let's say portability is important. What's the best type punning method to achieve lowest latency? It seems like memcpy() is the only choice? Thanks in advance. On Saturday, September 13, 2014 3:23 PM, Andrew Haley <aph@xxxxxxxxxx> wrote: On 12/09/14 23:58, haynberg@xxxxxxxxx wrote: >> Firstly, char types alias everything. > (I'm not sure why you wrote that?) Because the specification says so. 6.3.2.3, Pointers, in C9X. > I know if you cast to char type, > it can, but I'm going from a char type. > >> Secondly, even if you call memcpy(), a compiler doesn't have to do any >> copies if it can prove that the union you're reading into doesn't >> escape. > If the compiler can optimize away memcpy, why memcpy into a union, why > not just to the type in question? Or is memcpy into a union special? You can copy the bytes from one object to another, and it has the same effect. I can't guarantee it generates the same code as a union in all cases. > In other words, if I write: > > msg p; > memcpy(&p, get_bytes(), sizeof p); // assume the size OK > if (p.i) > // ... > > Can the memcpy be optimized away, making it similar to the cast version > (but not undefined)? Sure. Try it. >>> Putting alignment/padding concerns aside > FYI, I meant assume I'm on x86, or hardware that allows unaligned reads, > and my struct doesn't have padding issues. For example, sending a pragma > packed struct over a socket. > >>> Another related, maybe more important, question is if GCC sees a >>> reinterpet_cast like this (without a may_alias type), is it free to >>> discard code or otherwise drastically change it due to the fact that >>> it’s undefined by the standard? >> >> Yes. It may, and it does. > At some point, I understand GCC began to optimize more heavily in > strict-aliasing opportunities. For future reference, when GCC makes > changes like this, are they always mentioned in the release notes or > someplace else? Not AFAIK. We take the view that GCC is free to optimize as much as possible, subject to the constraints of the language. And, of course, we can't always predict what an optimization might do to every buggy program. Andrew.
