Hi Luc, > > > Calls to rte_memcpy_generic could result in unaligned loads/stores for > > > 1 < n < 16. This is undefined behavior according to the C standard, > > > and it gets flagged by the clang undefined behavior sanitizer. > > > > > > rte_memcpy_generic is called with unaligned src and dst addresses. > > > When 1 < n < 16, the code would cast both src and dst to a qword, > > > dword or word pointer, without verifying the alignment of src/dst. The > > > code was changed to use a packed structure to perform the unaligned > > > load/store operations. This results in unaligned load/store operations > > > to be C standards-compliant. > > > > Still not sure we need to fix that: > > This is x86 specific code-path, and as I remember on x86 there are no > > penalties for unaligned access to 2/4/8 byte values. > > Though I like introduction of rte_mov15_or_less() function -t helps > > with code dedup. > > Thanks for your input Konstantin. Much appreciated. Just to make sure > I understand, can you please confirm that we do not want to fix the > fact that unaligned access in C is undefined behaviour?
Yes, I don't think it is a real problem in that particular case. > I understand > that X86 allows unaligned accesses but since this isn't assembly code, > we have to go by what the C standard allows. > Also, do you have any opinion on the strict aliasing violation (as was > pointed out by Georg)? I suggested adding __may_alias__ thinking it > would likely fix the issue, but I'd really like to get confirmation > from someone who has better knowledge of how the attribute works > exactly. Not sure I understand the problem you are referring to. Are you saying that original rte_memcpy() code breaks strict aliasing? If so, could you point where exactly?