[LLVMbugs] [Bug 18912] New: Optimizer should consider "maythrow" calls (those without "nounwind) as having side effects.
bugzilla-daemon at llvm.org
bugzilla-daemon at llvm.org
Thu Feb 20 14:19:33 PST 2014
http://llvm.org/bugs/show_bug.cgi?id=18912
Bug ID: 18912
Summary: Optimizer should consider "maythrow" calls (those
without "nounwind) as having side effects.
Product: new-bugs
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedbugs at nondot.org
Reporter: atrick at apple.com
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
We should not allow instructions with potential side effects to move
across mayThrow calls. This is an informally accepted interpretation of
the LLVM SPEC. However, in practice, optimizations rely too heavily on
the presence of memory writes to model side effects.
We want to be able to define a call as "readonly" and *not* "nounwind". We want
to be able to eliminate redundant loads across such calls, however, we do not
want potentially unsafe loads to be hoisted above such calls. We also do not
want to allow such calls to be reordered with respect to each other, and other
readonly && mayThrow instructions.
This is important for implementing runtime calls, as commonly needed for high
level language constructs. It also allows llvm.experimental.stackmap to be
modeled correctly.
The purpose of this PR is to complete an audit of the optimizer/codegen to
catch cases that violate the assumptions above, improve the API, and better
document this requirement.
Here is just one example where codegen violates the rule:
int32_t foo(int32_t* ptr) {
int i = 0;
int result;
do {
bar(ptr);
result = *ptr;
bar(ptr);
} while (i++ < *ptr);
return result;
}
declare void @bar(i32*) readonly;
(So 'bar' is 'readonly' and 'may-unwind')
When LICM tries to sink the calls to 'bar', it sees the 'readonly', assumes no
side effects and sinks it below the loads.
--
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/20140220/3a6520af/attachment.html>
More information about the llvm-bugs
mailing list