https://bugs.llvm.org/show_bug.cgi?id=52423
Bug ID: 52423
Summary: LFTR with wide backedge taken counts
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Loop Optimizer
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Created attachment 25423
--> https://bugs.llvm.org/attachment.cgi?id=25423&action=edit
WIP patch
This was noticed in the context of D109457, I don't yet know if it shows up
elsewhere, but I expect so.
test case:
; RUN: opt -indvars < %s -S
target datalayout =
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64"
declare void @bar()
define void @slt_constant_rhs(i16 %n.raw, i8 %start) mustprogress {
entry:
br label %for.body
for.body: ; preds = %entry, %for.body
%iv = phi i8 [ %iv.next, %for.body ], [ %start, %entry ]
%iv.next = add i8 %iv, 1
call void @bar()
%zext = zext i8 %iv.next to i16
%cmp = icmp slt i16 %zext, 254
br i1 %cmp, label %for.body, label %for.end
for.end: ; preds = %for.body, %entry
ret void
}
With D109457 applied - so that we can compute a trip count for the loop - we
should be able to LFTR this loop.
Tracing through the code, we don't because the width of the BTC is 16, but the
width of the IV is 8. We unconditional reject this case.
I've attached a WIP patch which tries to check to see if we could legally
narrow the BTC, but it requires a few missing simplifications.
If D109457 ever lands, I'll probably finish this. I'm logging the bug mostly
so that the limitation doesn't get forgotten.
--
You are receiving this mail because:
You are on the CC list for the bug._______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
