<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Jul 21, 2013, at 11:55 PM, Duncan Sands <<a href="mailto:baldrick@free.fr">baldrick@free.fr</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Hi Andrew,<br><br>On 22/07/13 02:56, Andrew Trick wrote:<br><blockquote type="cite">Does 'nounwind' have semantics that inform optimization passes? It seems to in some cases, but not consistently. For example...<br><br>int32_t foo(int32_t* ptr) {<br> int i = 0;<br> int result;<br> do {<br> bar(ptr);<br> result = *ptr;<br> bar(ptr);<br> } while (i++ < *ptr);<br> return result;<br>}<br><br>Say we have a front end that declares bar as...<br><br>declare void @bar(i32*) readonly;<br><br>So 'bar' is 'readonly' and 'may-unwind'.<br><br>When LICM tries to hoist the load it interprets the 'may-unwind' as "MayThrow" in LICM-language and bails. However, when it tries to sink the call itself it sees the 'readonly', assumes no side effects and sinks it below the loads. Hmm...<br></blockquote><br>is your worry here about the following case?<br>- the load will trap if executed<br>- bar throws an exception<br>Thus with the original code the trap will not occur, because an exception will<br>be thrown first, while if you move the first bar call below the load then the<br>tap will occur.<br></div></blockquote><div><br></div><div>Essentially, yes. My takeaway from looking into it is:</div><div><br></div><div>- nounwind means no dwarf EH. Absence of nounwind means absence of dwarf EH. It would be unwise for optimization passes to reason about the semantics beyond that. I was momentarily mislead by the LICM code that handles MayThrow specially.</div><div><br></div><div>- Things that throw exceptions or trap in defined ways are not readonly.</div><div><br></div><div>- Runtime checks for overflow, div-by-zero, bounds checks, etc. should be implemented at the IR level as branches to noreturn calls because it can be done that way and I haven’t seen concrete evidence that it’s too expensive. Don’t try to do something fancy with intrinsics and attributes unless absolutely required.</div><div><br></div><div>- Optimizing readonly calls in C is a tangentially related issue, as Nick explained. My answer to that problem is that C compilers are effectively forced to assume that calls terminate, so developers should not expect otherwise. If C developers don’t want the compiler to optimize their infinite loop or infinite recursion, they need to throw in a volatile dereference.</div><div><br></div><div>-Andy</div><br><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite"><br>There doesn't appear to be a way to declare a function that is guaranteed not to write to memory in a way that affects the caller, but may have another well-defined side effect like aborting the program.<br></blockquote><br>I'm pretty sure that exiting the program is considered to write memory, so bar<br>can't do that itself.<br><br>Ciao, Duncan.<br><br>This is interesting, because that is the way runtime checks for safe languages would like to be defined. I'm perfectly happy telling front ends to generate control flow for well-defined traps, since I like lots of basic blocks in my IR. But I'm still curious how others deal with this.<br><blockquote type="cite"><br>-Andy<br>_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a><span class="Apple-converted-space"> </span> <a href="http://llvm.cs.uiuc.edu/">http://llvm.cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br><br></blockquote><br>_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a><span class="Apple-converted-space"> </span> <a href="http://llvm.cs.uiuc.edu/">http://llvm.cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a></div></blockquote></div><br></body></html>