<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 1, 2016, at 1:43 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" class="">dblaikie@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: 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;" class="">It may be that other approaches, more like the diagnostic handling options discussed in the original thread (& that we have plumbed through for the "remarks" support). But maybe you need a hard stop on these errors, in which case you do need some implicit or explicit control flow to get you out. There was a bit of discussion about how to do this for lld recently - returning stub results that are "sufficient" maybe with a flag saying "this isn't a real result" - more like Clang's Parser/Sema: we don't have error results everywhere. We return erroneous stubs and the like which allow a lot of Clang to continue on without worrying about whether something failed. Only handling the failures in relatively few places.</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: 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;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: 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;" class="">This is also useful for providing error recovery/multiple errors (eg: this instruction /and/ thin instruction were both wrong - so the user doesn't have to edit/compile loop again just to find out the two lines they wrote both needed changes). </div></div></blockquote></div><br class=""><div class="">I can speak only to my own use case here: if my frontend provided me with contract-violating IR, I want to propagate an error all the way out to the the client (non-LLVM code) such that (1) they can log/report the error as appropriate for the platform, to aid in future debug, and (2) to give them a chance to recover via higher-order mechanisms such as falling back to a lower tier JIT, to an interpreter, or simply to an unoptimized compilation. My impression is that #2 tends to get overlooked here, but many online and JIT compilation use cases have reasonable fallbacks options to continue program execution even if LLVM fails in a nominally unrecoverable manner.</div><div class=""><br class=""></div><div class="">—Owen</div></body></html>