[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


            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 { 
    result = *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