<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - Loop Access Analysis missing an analyzable stride?"
href="https://bugs.llvm.org/show_bug.cgi?id=32694">32694</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Loop Access Analysis missing an analyzable stride?
</td>
</tr>
<tr>
<th>Product</th>
<td>libraries
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>Loop Optimizer
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>paulsson@linux.vnet.ibm.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=18300" name="attach_18300" title="reduced test case with loop that gives 16 scalarized adjacent stores">attachment 18300</a> <a href="attachment.cgi?id=18300&action=edit" title="reduced test case with loop that gives 16 scalarized adjacent stores">[details]</a></span>
reduced test case with loop that gives 16 scalarized adjacent stores
The loop vectorizer is looking at this loop:
for.body617: ; preds =
%for.body617.preheader, %for.body617
%indvars.iv = phi i64 [ %1, %for.body617.preheader ], [ %indvars.iv.next,
%for.body617 ]
%2 = load i8*, i8** @stack_usage_map, align 8, !tbaa !1
%arrayidx619 = getelementptr inbounds i8, i8* %2, i64 %indvars.iv
store i8 1, i8* %arrayidx619, align 1, !tbaa !5
%indvars.iv.next = add nsw i64 %indvars.iv, 1
%cmp615 = icmp slt i64 %indvars.iv, -1
br i1 %cmp615, label %for.body617, label %for.cond496.loopexit
LAI does not see that the store i8 is adding the IV to a loop invariant base
register. It seems to think that the %2 is a loop varying register:
LAA: Bad stride - Not an AddRecExpr pointer %arrayidx619 = getelementptr
inbounds i8, i8* %2, i64 %indvars.iv SCEV: ({(sext i32 %i.0.ph to i64),+
,1}<nsw><%for.body617> + %2)<nsw>
%2 is actually a loop invariant load of a pointer, and I am wondering if this
is a deficiency that could be fixed? If not, I am curious why this is not safe?
The attached file was reduced automatically, and I hope it serves the purpose
for demonstration.
bin/opt -mtriple=s390x-unknown-linux -mcpu=z13 -O3 ./stores_16i8.ll -o
./out.opt.ll -S
The vectorizer output is 16 scalarized stores adjacent stores (which in this
case the backend manages to combine luckily...)
vector.body: ; preds =
%vector.body.preheader, %vector.body
%index = phi i64 [ %index.next, %vector.body ], [ 0, %vector.body.preheader ]
%offset.idx = add i64 %index, %3
%7 = add i64 %index, %3
%8 = add i64 %offset.idx, 1
%9 = add i64 %offset.idx, 2
%10 = add i64 %offset.idx, 3
%11 = add i64 %offset.idx, 4
%12 = add i64 %offset.idx, 5
%13 = add i64 %offset.idx, 6
%14 = add i64 %offset.idx, 7
%15 = add i64 %offset.idx, 8
%16 = add i64 %offset.idx, 9
%17 = add i64 %offset.idx, 10
%18 = add i64 %offset.idx, 11
%19 = add i64 %offset.idx, 12
%20 = add i64 %offset.idx, 13
%21 = add i64 %offset.idx, 14
%22 = add i64 %offset.idx, 15
%23 = getelementptr inbounds i8, i8* %0, i64 %7
%24 = getelementptr inbounds i8, i8* %0, i64 %8
%25 = getelementptr inbounds i8, i8* %0, i64 %9
%26 = getelementptr inbounds i8, i8* %0, i64 %10
%27 = getelementptr inbounds i8, i8* %0, i64 %11
%28 = getelementptr inbounds i8, i8* %0, i64 %12
%29 = getelementptr inbounds i8, i8* %0, i64 %13
%30 = getelementptr inbounds i8, i8* %0, i64 %14
%31 = getelementptr inbounds i8, i8* %0, i64 %15
%32 = getelementptr inbounds i8, i8* %0, i64 %16
%33 = getelementptr inbounds i8, i8* %0, i64 %17
%34 = getelementptr inbounds i8, i8* %0, i64 %18
%35 = getelementptr inbounds i8, i8* %0, i64 %19
%36 = getelementptr inbounds i8, i8* %0, i64 %20
%37 = getelementptr inbounds i8, i8* %0, i64 %21
%38 = getelementptr inbounds i8, i8* %0, i64 %22
store i8 1, i8* %23, align 1, !tbaa !5
store i8 1, i8* %24, align 1, !tbaa !5
store i8 1, i8* %25, align 1, !tbaa !5
store i8 1, i8* %26, align 1, !tbaa !5
store i8 1, i8* %27, align 1, !tbaa !5
store i8 1, i8* %28, align 1, !tbaa !5
store i8 1, i8* %29, align 1, !tbaa !5
store i8 1, i8* %30, align 1, !tbaa !5
store i8 1, i8* %31, align 1, !tbaa !5
store i8 1, i8* %32, align 1, !tbaa !5
store i8 1, i8* %33, align 1, !tbaa !5
store i8 1, i8* %34, align 1, !tbaa !5
store i8 1, i8* %35, align 1, !tbaa !5
store i8 1, i8* %36, align 1, !tbaa !5
store i8 1, i8* %37, align 1, !tbaa !5
store i8 1, i8* %38, align 1, !tbaa !5
%index.next = add i64 %index, 16
%39 = icmp eq i64 %index.next, %n.vec
br i1 %39, label %middle.block, label %vector.body, !llvm.loop !6</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>