[PATCH] D150706: [LAA] Update MaxSafeDepDistBytes when non-unit stride

Florian Hahn via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jul 19 00:51:10 PDT 2023


fhahn added a comment.

In D150706#4507201 <https://reviews.llvm.org/D150706#4507201>, @michaelmaitland wrote:

>> But does LV miscompile the case?
>
> No, but I believe that the `MaxSafeVectorWidthInBits` is incorrect prior to this patch, and we just happen to not vectorize based on incorrect values.

Looking at. https://llvm.godbolt.org/z/hK8xnbM6G, LV 'vectorizes' with VF=2 (it scalarizes all loads & stores, but still reorders them), but not with VF=4 due to memory conflicts.

I think with respect to `MaxSafeDepDistBytes` it is still not clear to me that the current value is incorrect, as it is just the distance computed between 2 dependencies and in the test the distance between `%arrayidx2` and `%%arrayidx5` is 24 bytes AFAICT.

In D150706#4507183 <https://reviews.llvm.org/D150706#4507183>, @michaelmaitland wrote:

> In D150706#4506975 <https://reviews.llvm.org/D150706#4506975>, @fhahn wrote:
>
>> It might be helpful to also print  `MaxSafeVectorWidthInBits`
>
> I added this print out and checked it with the test. Before this patch, we reported `The maximum number of bits that are safe to operate on in parallel is 64`, which is incorrect.

Thanks! The raw distance between the accesses is 24 bytes, the stride per iteration is 12, so we should be able to execute 2 iterations in parallel unless I am missing something. We are accessing `i32` types, so in 2 iterations we would access 64 bits.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D150706



More information about the llvm-commits mailing list