================ @@ -1,57 +1,53 @@ ; NOTE: Assertions have been autogenerated by utils/update_test_checks.py UTC_ARGS: --check-globals none --version 6 ; RUN: opt < %s -p loop-vectorize -force-vector-width=4 -S \ -; RUN: -enable-mem-access-versioning=false 2>&1 | FileCheck %s --check-prefix COMPARE-NO-MV +; RUN: -enable-mem-access-versioning=false -enable-vplan-based-stride-mv 2>&1 | FileCheck %s --check-prefix COMPARE-NO-MV ; RUN: opt < %s -p loop-vectorize -force-vector-width=4 -S \ -; RUN: -enable-mem-access-versioning=true 2>&1 | FileCheck %s --check-prefix COMPARE-LAA-MV +; RUN: -enable-mem-access-versioning=false -enable-vplan-based-stride-mv 2>&1 | FileCheck %s --check-prefix COMPARE-LAA-MV ---------------- eas wrote:
I was sure I replied to your original question but somehow I didn't. To answer that first > How come these RUN lines are the same? RUN lines are identical and one of them will be dropped in a subsequent PR after this lands. The reason I have two is that they generate diffs against two different baselines to give more context to the reviewers. > Am I right in that the VPlan flag is not meant as an experimental flag, but > rather to prevent multiversioning anyway when > -enable-mem-access-versioning=false? In my mind it is meant as an experimental flag until LAA is improved not to bailout on RT-strided dependence checks. > the vplan based unit-strideness speculation doesn't kick in unless > -enable-mem-access-versioning=false is also false. Not sure how important that question is given my answer about "experimental" nature above, but I think the state is as follows: - In current version using `RecipeBuilder.isConsecutiveWithoutVPlanBasedStrideSpeculation` would ignore unit-strided accesses speculated in LAI - I'm not sure if `widenConsecutiveMemOps` from #211315 would widen those or not, but we shouldn't be running in a mode when both LAA and VPlan stride speculation are enabled simultaneously anyway. https://github.com/llvm/llvm-project/pull/182595 _______________________________________________ llvm-branch-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
