[llvm] [CodeGen] Avoid sinking vector comparisons during CodeGenPrepare (PR #113158)
David Sherwood via llvm-commits
llvm-commits at lists.llvm.org
Tue Nov 5 01:52:07 PST 2024
================
@@ -0,0 +1,136 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py UTC_ARGS: --version 5
+; RUN: llc -mtriple=thumbv8.1m.main -mattr=+mve.fp,+fp-armv8d16sp,+fp16,+fullfp16 < %s | FileCheck %s
+
+define arm_aapcs_vfpcc void @vector_loop_with_icmp(ptr nocapture noundef writeonly %dest) {
+; CHECK-LABEL: vector_loop_with_icmp:
+; CHECK: @ %bb.0: @ %entry
+; CHECK-NEXT: push.w {r4, r5, r6, r7, r8, r9, lr}
+; CHECK-NEXT: adr r1, .LCPI0_0
+; CHECK-NEXT: adr r2, .LCPI0_1
+; CHECK-NEXT: vldrw.u32 q0, [r1]
+; CHECK-NEXT: vldrw.u32 q1, [r2]
+; CHECK-NEXT: movs r1, #0
+; CHECK-NEXT: mov.w r12, #1
+; CHECK-NEXT: mov.w lr, #0
+; CHECK-NEXT: .LBB0_1: @ %vector.body
+; CHECK-NEXT: @ =>This Inner Loop Header: Depth=1
+; CHECK-NEXT: vmov r2, r3, d0
+; CHECK-NEXT: vmov r4, r5, d3
+; CHECK-NEXT: vmov r6, r7, d1
+; CHECK-NEXT: subs r2, #15
+; CHECK-NEXT: sbcs r2, r3, #0
+; CHECK-NEXT: cset r2, lo
+; CHECK-NEXT: cmp r2, #0
+; CHECK-NEXT: vmov r2, r3, d1
+; CHECK-NEXT: it ne
+; CHECK-NEXT: strne.w r12, [r0, r1, lsl #2]
+; CHECK-NEXT: subs r2, #15
+; CHECK-NEXT: sbcs r2, r3, #0
+; CHECK-NEXT: cset r2, lo
+; CHECK-NEXT: cmp r2, #0
+; CHECK-NEXT: itt ne
+; CHECK-NEXT: orrne r2, r1, #1
+; CHECK-NEXT: strne.w r12, [r0, r2, lsl #2]
+; CHECK-NEXT: vmov r2, r3, d2
+; CHECK-NEXT: subs r2, #15
+; CHECK-NEXT: sbcs r2, r3, #0
+; CHECK-NEXT: cset r2, lo
+; CHECK-NEXT: cmp r2, #0
+; CHECK-NEXT: itt ne
+; CHECK-NEXT: orrne r2, r1, #2
+; CHECK-NEXT: strne.w r12, [r0, r2, lsl #2]
+; CHECK-NEXT: vmov r2, r3, d3
+; CHECK-NEXT: subs r2, #15
+; CHECK-NEXT: sbcs r2, r3, #0
+; CHECK-NEXT: cset r2, lo
+; CHECK-NEXT: cmp r2, #0
+; CHECK-NEXT: itt ne
+; CHECK-NEXT: orrne r2, r1, #3
+; CHECK-NEXT: strne.w r12, [r0, r2, lsl #2]
+; CHECK-NEXT: vmov r2, r3, d2
+; CHECK-NEXT: adds r1, #4
+; CHECK-NEXT: adc lr, lr, #0
+; CHECK-NEXT: adds.w r9, r2, #4
+; CHECK-NEXT: adc r8, r3, #0
+; CHECK-NEXT: vmov r3, r2, d0
+; CHECK-NEXT: adds r4, #4
+; CHECK-NEXT: adc r5, r5, #0
+; CHECK-NEXT: adds r6, #4
+; CHECK-NEXT: adc r7, r7, #0
+; CHECK-NEXT: vmov q1[2], q1[0], r9, r4
+; CHECK-NEXT: vmov q1[3], q1[1], r8, r5
+; CHECK-NEXT: adds r3, #4
+; CHECK-NEXT: vmov q0[2], q0[0], r3, r6
+; CHECK-NEXT: adc r2, r2, #0
+; CHECK-NEXT: vmov q0[3], q0[1], r2, r7
+; CHECK-NEXT: eor r2, r1, #16
+; CHECK-NEXT: orrs.w r2, r2, lr
+; CHECK-NEXT: bne .LBB0_1
+; CHECK-NEXT: @ %bb.2: @ %for.cond.cleanup
+; CHECK-NEXT: pop.w {r4, r5, r6, r7, r8, r9, pc}
+; CHECK-NEXT: .p2align 4
+; CHECK-NEXT: @ %bb.3:
+; CHECK-NEXT: .LCPI0_0:
+; CHECK-NEXT: .long 0 @ 0x0
+; CHECK-NEXT: .long 0 @ 0x0
+; CHECK-NEXT: .long 1 @ 0x1
+; CHECK-NEXT: .long 0 @ 0x0
+; CHECK-NEXT: .LCPI0_1:
+; CHECK-NEXT: .long 2 @ 0x2
+; CHECK-NEXT: .long 0 @ 0x0
+; CHECK-NEXT: .long 3 @ 0x3
+; CHECK-NEXT: .long 0 @ 0x0
+entry:
+ br label %vector.body
+
+vector.body:
+ %index = phi i64 [ 0, %entry ], [ %index.next, %pred.store.continue18 ]
+ %vec.ind = phi <4 x i64> [ <i64 0, i64 1, i64 2, i64 3>, %entry ], [ %vec.ind.next, %pred.store.continue18 ]
+ %0 = icmp ult <4 x i64> %vec.ind, <i64 15, i64 15, i64 15, i64 15>
----------------
david-arm wrote:
Oh of course you're right. I think I took the output from the vectoriser for AArch64 and then tried to recreate a MVE test from it. If I compile
```
void foo(int *dest) {
for (int i = 0; i < 14; i++) {
dest[i] = 3;
}
}
```
with
```
clang -O3 -fno-unroll-loops --target=thumb-linux-gnueabi -mcpu=cortex-m55 -mllvm -tail-predication=disabled -S -emit-llvm ./lowtrip.c
```
then I see
```
vector.body: ; preds = %vector.body, %entry
%index = phi i32 [ 0, %entry ], [ %index.next, %vector.body ]
%broadcast.splatinsert = insertelement <4 x i32> poison, i32 %index, i64 0
%broadcast.splat = shufflevector <4 x i32> %broadcast.splatinsert, <4 x i32> poison, <4 x i32> zeroinitializer
%vec.iv = or disjoint <4 x i32> %broadcast.splat, <i32 0, i32 1, i32 2, i32 3>
%0 = icmp ult <4 x i32> %vec.iv, <i32 14, i32 14, i32 14, i32 14>
%1 = getelementptr inbounds i32, ptr %dest, i32 %index
tail call void @llvm.masked.store.v4i32.p0(<4 x i32> <i32 3, i32 3, i32 3, i32 3>, ptr %1, i32 4, <4 x i1> %0), !tbaa !5
%index.next = add i32 %index, 4
%2 = icmp eq i32 %index.next, 16
br i1 %2, label %for.cond.cleanup, label %vector.body, !llvm.loop !9
```
I think a better example where it goes wrong is:
```
void foo(short *dest) {
for (int i = 0; i < 14; i++) {
dest[i] = 3;
}
}
```
where the vectoriser output is:
```
vector.body: ; preds = %vector.body, %entry
%index = phi i32 [ 0, %entry ], [ %index.next, %vector.body ]
%broadcast.splatinsert = insertelement <8 x i32> poison, i32 %index, i64 0
%broadcast.splat = shufflevector <8 x i32> %broadcast.splatinsert, <8 x i32> poison, <8 x i32> zeroinitializer
%vec.iv = or disjoint <8 x i32> %broadcast.splat, <i32 0, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7>
%0 = icmp ult <8 x i32> %vec.iv, <i32 14, i32 14, i32 14, i32 14, i32 14, i32 14, i32 14, i32 14>
%1 = getelementptr inbounds i16, ptr %dest, i32 %index
tail call void @llvm.masked.store.v8i16.p0(<8 x i16> <i16 3, i16 3, i16 3, i16 3, i16 3, i16 3, i16 3, i16 3>, ptr %1, i32 2, <8 x i1> %0), !tbaa !5
%index.next = add i32 %index, 8
%2 = icmp eq i32 %index.next, 16
br i1 %2, label %for.cond.cleanup, label %vector.body, !llvm.loop !9
```
and this time the <8 x i32> isn't ideal - we could in fact have chosen <8 x i16>. Anyway, for the purpose of this particular PR it doesn't matter I suppose. I'll amend the test to use i32!
https://github.com/llvm/llvm-project/pull/113158
More information about the llvm-commits
mailing list