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

[Philip Reames via llvm-dev]

+1 to what James said.  My reaction to the original proposal is a strong 
-1, and James did a good job of explaining why.

Philip

On 4/14/21 11:57 AM, James Y Knight via llvm-dev wrote:
> This is not a principled change -- it avoids a problem arising from 
> /one/ use of alignment information, but there are other uses of 
> alignment in LLVM, and those will still cause problems, potentially 
> less clearly. So, I think that this will not be a useful option to 
> provide to users, in this form.
>
> What I suspect you /actually/ want here is an option to tell Clang not 
> to infer load/store alignments based on object types or alignment 
> attributes -- instead treating everything as being potentially aligned 
> to 1 unless the allocation is seen (e.g. global/local variables). 
> Clang would still need to use the usual alignment computation for 
> variable definitions and structure layout, but not memory operations. 
> If clang emits "load ... align 1" instructions in LLVM IR, the right 
> thing would then happen in the X86 backend automatically.
>
> My initial inclination is that this feature is also not 
> particularly worthwhile to implement, but I'm open to being convinced 
> that this is indeed valuable enough to be worthwhile. It should 
> actually work reliably, and is somewhat in line with other such 
> "not-quite-C" flags we provide (e.g. -fno-delete-null-pointer-checks). 
> Of course, even with such an implementation, you can still have a 
> problem with user code depending on alignof() returning a reliable 
> answer (e.g., llvm::PointerUnion). Not much can be done about that.
>
>
> On Wed, Apr 14, 2021 at 2:07 PM Liu, Chen3 via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
>     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;
>
>      3. 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.
>      4. 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
>     <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 <https://reviews.llvm.org/D88396>
>     (abandoned)
>
>     https://reviews.llvm.org/D99565 <https://reviews.llvm.org/D99565>
>     (in review)
>
>     Thanks.
>
>     Chen Liu.
>
>     _______________________________________________
>     LLVM Developers mailing list
>     llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>     https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>     <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210414/50853178/attachment-0001.html>