6 ms·
That looks like it could result in unaligned access and hence a crash on sparc64.
by cbmuser 6y ago
That looks like it could result in unaligned access and hence a crash on sparc64.
- kazinator 6y agoThus, it can't compile that way for sparc64.
- giovannibajo1 6y agoThat’s fine, GCC on sparc will generate the sequence to do an unaligned read with the right endianess. If that means reading bytes and shifting them, so be it.
- EdSchouten 6y agoExactly. And even if we want to optimize access for those architectures, there surely must be ways to do that. Maybe compilers already do that if you use alignas(int32_t) on the byte array at the call site and ensure that read_int32() function of mine gets inlined?
- giovannibajo1 6y agoNo they won’t, if not in very basic cases that can’t be generalized as a rule of thumb solution. Your suggestion bargains correctness with performance. If you know you are reading aligned memory and you need to do it with a single word memory access, then you need to use intNN_t* and use htonl or similar functions to byteswap. There’s no way around it.
- kazinator 6y agoThe compiler can generate a test for alignment, and then a branch between two pieces of code. However, if the test and branch branch causes pipeline stalls due to bad prediction, it could be worse than just running the byte-banging code unconditionally.
- kazinator 6y agoI.e. "if that means doing what the programmer literally expressed, so be it."
- EdSchouten 6y agoHow? We’re just reading from a byte array.
- josefx 6y agoThe optimized code assumes it can read a full 32 bit value at once. So at least that is only valid on a platform that doesn't assume that 32 bit loads are aligned and the actual compiled code would look a lot worse on platforms that do.