On Tue, May 04, 2021 at 02:30:50PM -0700, Eric Biggers wrote: > > So maybe the memcpy to a local copy is the better way to go, and > > hopefully the C compiler will optimize away the local copy on > > architectures where it is safe to do so. And in the unlikely case > > that it is a performance bottleneck, we could add a -DUBSAN when > > configure --enable-ubsan is in force, which switches in the memcpy > > when only when ubsan is enabled. > > These days the memcpy() approach does get optimized properly. armv6 and armv7 > with gcc used to be a notable exception, but it got fixed in gcc 6 > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67366). > Just to be clear (looking at the latest patches on the list which are copying whole structs), by "the memcpy() approach does get optimized properly", I meant that it gets optimized properly in implementations of get_unaligned_le16(), get_unaligned_le32(), put_unaligned_le32(), etc., where a single word (or less than a word) is loaded or stored. I don't know how reliably the compilers will optimize out the copy if you memcpy() a whole struct instead of a single word. Even if they don't optimize it out, I don't expect that it would be a performance problem in this context, so it's probably still fine to solve the problem. But I just wanted to clarify what I meant here. - Eric
