[PATCH] D88396: [X86] Support replacing aligned vector moves with unaligned moves when avx is enabled. (off by default)

[LuoYuanke via Phabricator via llvm-commits]

LuoYuanke added a comment.

In D88396#2323333 <https://reviews.llvm.org/D88396#2323333>, @lebedev.ri wrote:

> In D88396#2323332 <https://reviews.llvm.org/D88396#2323332>, @pengfei wrote:
>
>> LGTM. Thanks!
>> Since the pass is turned off by default, I think we can let it in. @lebedev.ri, what's your opinion?
>
> I still retain my original opinion that this is trying to paper over broken source code,
> and incorrectly so, because even if backend doesn't make use of the alignment information
> that was lowered from the source code into IR, the IR will still contain incorrect alignment
> information, and it is only a matter of time until that UB manifests in some other way.
>
> As i see it, there are 5 options:
>
> 1. Don't manually vectorize the code
> 2. Do UBSan to catch these issues
> 3. Enhance clang/clang-tidy to better catch these issues
> 4. Don't do aligned loads https://godbolt.org/z/38jrvE
> 5. Add a clang (!) switch to make `__m128` unaligned
>
> I strongly suggest that an option 4 be taken.

I think it is friendly for compiler to provide an opportunity to let user decide whether he/she prefer aligned load or unaligned load. As I know some processor also have some control register to control raising or suppressing exception on unaligned memory access. Leaving the decision to user doesn't harm any existing behavior. For X86 we have a choice to select aligned instruction or unaligned instruction. What if some processor only have instruction that don't raise exception on unaligned memory access?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88396/new/

https://reviews.llvm.org/D88396