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

[Roman Lebedev via Phabricator via llvm-commits]

lebedev.ri resigned from this revision.
lebedev.ri added a comment.

In D88396#2323356 <https://reviews.llvm.org/D88396#2323356>, @LuoYuanke wrote:

> 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?

I think we are talking past each other.
Do you agree that even with this patch, the LLVM IR will still contain an incorrect alignment on loads (`align 16`, https://godbolt.org/z/4d8xM3)?
Do you agree that it is an undefined behaviour?
Do you agree that by only hiding that fact in the back-end, the middle end optimization pipeline is still free to make use of that incorrect information to miscompile the code?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88396