; RUN: opt -loop-vectorize -S < %s | FileCheck %s target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128-ni:1" target triple = "x86_64-unknown-linux-gnu" ; PR34965/D39346 ; LV retains the original scalar loop intact as remainder loop. However, ; after this transformation, analysis information concerning the remainder ; loop may differ from the original scalar loop. This test is an example of ; that behaviour, where values inside the remainder loop which SCEV could ; originally analyze now require flow-sensitive analysis currently not ; supported in SCEV. In particular, during LV code generation, after turning ; the original scalar loop into the remainder loop, LV expected ; Legal->isConsecutivePtr() to be consistent and return the same output as ; during legal/cost model phases (original scalar loop). Unfortunately, that ; condition was not satisfied because of the aforementioned SCEV limitation. ; After D39346, LV code generation doesn't rely on Legal->isConsecutivePtr(), ; i.e., SCEV. This test verifies that LV is able to handle the described cases. ; ; TODO: The SCEV limitation described before may affect plans to further ; optimize the remainder loop of this particular test case. One tentative ; solution is to detect the problematic IVs in LV (%7 and %8) and perform an ; in-place IV optimization by replacing: ; %8 = phi i32 [ %.ph2, %.outer ], [ %7, %6 ] with ; with ; %8 = sub i32 %7, 1. ; Verify that store is vectorized as stride-1 memory access. ; CHECK-LABEL: @test_01( ; CHECK-NOT: vector.body: ; This test was originally vectorized, but now SCEV is smart enough to prove ; that its trip count is 1, so it gets ignored by vectorizer. ; Function Attrs: uwtable define void @test_01() { br label %.outer ;