[LLVMbugs] [Bug 20811] New: [GVN, EarlyCSE, Missed Opt] Load from memory after invariant.end is undef
bugzilla-daemon at llvm.org
bugzilla-daemon at llvm.org
Fri Aug 29 14:42:48 PDT 2014
http://llvm.org/bugs/show_bug.cgi?id=20811
Bug ID: 20811
Summary: [GVN, EarlyCSE, Missed Opt] Load from memory after
invariant.end is undef
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedbugs at nondot.org
Reporter: listmail at philipreames.com
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
Created attachment 12960
--> http://llvm.org/bugs/attachment.cgi?id=12960&action=edit
Failing test case for GVN
Currently, GVN has handling to remove a load following a invariant.start with
no intervening stores since the memory is undefined and the load can be
replaced with undef. This is an analogous case for invariant.end which is not
implemented. Once the lifetime of a memory region has ended, the value of the
memory becomes undefined. As a result, a load from such memory should be
replaced with undef.
Here's the example case (also attached):
define i8 @test(i8* %P) nounwind {
entry:
call void @llvm.lifetime.end(i64 32, i8* %P)
%0 = load i8* %P <-- this load is undefined
ret i8 %0
}
The failing test case I've attached is for GVN, but EarlyCSE has the same
issue. (In fact, this load is not currently removed by an pass in -O3.) As
mentioned in 20809, it would be nice if the logic in question could be
refactored to be sharable between the two passes.
--
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/20140829/1fa1a4e7/attachment.html>
More information about the llvm-bugs
mailing list