<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 - DeadStoreElimination not handling non byte sized stores correctly (miscompile, asserts, etc)"
href="https://bugs.llvm.org/show_bug.cgi?id=41949">41949</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>DeadStoreElimination not handling non byte sized stores correctly (miscompile, asserts, etc)
</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>Scalar Optimizations
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>bjorn.a.pettersson@ericsson.com
</td>
</tr>
<tr>
<th>CC</th>
<td>efriedma@quicinc.com, llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>A test case like below ends up hitting an assert
opt: ../llvm/include/llvm/ADT/APInt.h:1419: void
llvm::APInt::setBits(unsigned int, unsigned int): Assertion `loBit <= BitWidth
&& "loBit out of range"' failed.
in DeadStoreElimination when handling partial overwrites.
;---------------------------------------------------------------------------------
; RUN: opt < %s --data-layout "e" -dse -S | FileCheck --check-prefix CHECK-LE
%s
; RUN: opt < %s --data-layout "E" -dse -S | FileCheck --check-prefix CHECK-BE
%s
define void @test1(i32* %P) {
%A = alloca i32
%B = bitcast i32* %A to i28*
%C = bitcast i32* %A to { i16, i16 }*
%C1 = getelementptr inbounds { i16, i16 }, { i16, i16 }* %C, i32 0, i32 1
store i28 10, i28* %B
store i16 20, i16* %C1
call void @test1(i32* %A)
ret void
}
;---------------------------------------------------------------------------------
I got a feeling that DeadStoreElmination doesn't consider cases when "size in
bits" and "store size in bits" differs. opt should probably not assume anything
about the padding bits (or the internal alignment) when storing X bits using a
store size of Y bits, and Y is greater than X.
Some other problems can be observed using test2 that looks like this:
;---------------------------------------------------------------------------------
; RUN: opt < %s --data-layout "e" -dse -S | FileCheck --check-prefix CHECK-LE
%s
; RUN: opt < %s --data-layout "E" -dse -S | FileCheck --check-prefix CHECK-BE
%s
define void @test2(i32* %p) {
%u = alloca i32
%a = bitcast i32* %u to i32*
%b = bitcast i32* %u to i12*
store i32 -1, i32* %a
store i12 20, i12* %b
call void @test2(i32* %u)
ret void
}
;---------------------------------------------------------------------------------
For @test2 we get a single i32 store like this for little endian
store i32 -4076, i32* %a ; 0xfffff014
so it does not care about that the i12 store has a 16-bit store size
Looks like bit 12-15 is taken from the first store. Or we at least have a
sitution
where opt is doing assumptions on where the padding bits are (and that it is OK
that they aren't zero).
And for big endian we get a single store like this
store i32 22020095, i32* %a ; 0x014fffff
which means that the memory will contain
p+0: 0x01
p+1: 0x4f
p+2: 0xff
p+3: 0xff
But normally when doing
store i12 20, p
I believe that we would get
p+0: 0x00
p+1: 0x14
So in this last case we get a miscompile.</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>