[llvm-dev] [RFC] [X86] Emit unaligned vector moves on avx machine with option control.

[Liu, Chen3 via llvm-dev]

Hi all.

We want to make a patch to always emit unaligned vector move instructions on AVX machine with option control. We do this for the following reason:


  1.  With AVX the performance for aligned vector move and unaligned vector move on X86 are the same if the address is aligned. In this case we prefer to use unaligned move because it can avoid some run time exceptions;
  2.  This fixes an inconsistency in optimization: suppose a load operation was merged into another instruction (e.g., load and add becomes `add [memop]'). If a misaligned pointer is passed to the two-instruction sequence, it will

raise an exception. If the same pointer is passed to the memop instruction, it will work. Thus, the behavior of misalignment depends upon what optimization levels and passes are applied, and small source changes could cause

issues to appear and disappear. It's better for the user to consistently use unaligned load/store to improve the debug experience;

  1.  Makes good use of HW that is capable of handling misaligned data gracefully. It is not necessarily a bug in users code but a third-part library. For example it would allow using a library built in old ages where stack alignment was 4-byte only.
  2.  Compatible with ICC so that users can easily use llvm;

Roman Lebedev is worried that this patch will hide UB. In our opinions, UB doesn't have to mean raise an exception. The example code(https://godbolt.org/z/43bYPraoa) does have UB behavior but it is still valid (and reasonable) to interpret that UB as `go slower',
instead of `raise exception'. Besides, as default we still emit aligned instructions as before,  but we provide an option for users with this need.

We have two patches discussing this issue, one of which has been abandoned:
https://reviews.llvm.org/D88396 (abandoned)
https://reviews.llvm.org/D99565 (in review)

Thanks.
Chen Liu.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210414/07bb0186/attachment.html>