[llvm-bugs] [Bug 28987] New: Regression in removing pointer range loops initializing dead variables.
via llvm-bugs
llvm-bugs at lists.llvm.org
Mon Aug 15 11:52:07 PDT 2016
https://llvm.org/bugs/show_bug.cgi?id=28987
Bug ID: 28987
Summary: Regression in removing pointer range loops
initializing dead variables.
Product: new-bugs
Version: 3.9
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedbugs at nondot.org
Reporter: edy.burt at gmail.com
CC: llvm-bugs at lists.llvm.org
Classification: Unclassified
The following function is optimized out in clang 3.8, but not 3.9:
void test() {
double a[4];
for(double *p = a, *end = a + 4; p < end; p++)
*p = 0.0;
}
The optimized IR on 3.9 is more or less:
define void @test() {
entry-block:
%a = alloca [4 x double], align 8
%a6 = ptrtoint [4 x double]* %a to i64
%0 = bitcast [4 x double]* %a to i8*
call void @llvm.lifetime.start(i64 32, i8* %0)
%scevgep = getelementptr [4 x double], [4 x double]* %a, i64 1, i64 0
%scevgep1 = ptrtoint double* %scevgep to i64
%scevgep2 = getelementptr [4 x double], [4 x double]* %a, i64 0, i64 1
%scevgep23 = ptrtoint double* %scevgep2 to i64
%1 = icmp ugt i64 %scevgep1, %scevgep23
%umax = select i1 %1, i64 %scevgep1, i64 %scevgep23
%umax45 = inttoptr i64 %umax to i8*
%2 = xor i64 %a6, -1
%uglygep = getelementptr i8, i8* %umax45, i64 %2
%uglygep7 = ptrtoint i8* %uglygep to i64
%3 = add i64 %uglygep7, 8
%4 = and i64 %3, -8
call void @llvm.memset.p0i8.i64(i8* %0, i8 0, i64 %4, i32 8, i1 false)
call void @llvm.lifetime.end(i64 32, i8* %0)
ret void
}
If the llvm.lifetime.{start,end} calls are removed, running opt again will
reduce this to just "ret void".
Any other uses of %a will also prevent the memset and everything before it to
be removed, *even* if the entire array is statically overwritten.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160815/45c64956/attachment.html>
More information about the llvm-bugs
mailing list