On Oct 13, 2008, at 12:42 PM, Chris Lattner wrote:>> >> Currently there no way to recover if the IR contains some >> construct that codegen can't handle. This is unfortunate for some >> applications. > > I completely agree, but these should not be fixed with exceptions: > this should be fixed by adding a direct failure reporting mechanism. > > -ChrisAndrew and I (and another faculty member here) are working on software recovery techniques for run-time errors that would otherwise be fatal, so I am curious about this answer. Why do you think these cases should not be fixed with exceptions? What if a client wants to *recover* in some manner, e.g., by emulating missing instructions or transforming the code (or any of a variety of other recovery strategies), but not just report a failure to the external world? --Vikram Associate Professor, Computer Science University of Illinois at Urbana-Champaign http://llvm.org/~vadve
On Oct 13, 2008, at 10:56 AM, Vikram S. Adve wrote:> Andrew and I (and another faculty member here) are working on software > recovery techniques for run-time errors that would otherwise be fatal, > so I am curious about this answer. Why do you think these cases > should not be fixed with exceptions? What if a client wants to > *recover* in some manner, e.g., by emulating missing instructions or > transforming the code (or any of a variety of other recovery > strategies), but not just report a failure to the external world?Exceptions have a high cost in terms of code size, binary size, and even a bit of execution time. Also, they don't magically make the code safe from any error: code has to be designed specifically to use RAII and other techniques to handle exceptions properly. Reading a C+ + trade magazines/books about EH topics will give you an idea of the complexity involved in doing it right. Further, as I mentioned up- thread, turning aborts into exception throws won't save you from null pointer or garbage pointer dereferences. As I said before, LLVM libraries have to serve multiple clients. Code size is a very important aspect of this. I'd love to build with -fno- rtti to get another 5% back. -Chris
On Oct 13, 2008, at 1:07 PM, Chris Lattner wrote:> > Exceptions have a high cost in terms of code size, binary size, and > even a bit of execution time. Also, they don't magically make the > code safe from any error: code has to be designed specifically to use > RAII and other techniques to handle exceptions properly. Reading a C+ > + trade magazines/books about EH topics will give you an idea of the > complexity involved in doing it right. Further, as I mentioned up- > thread, turning aborts into exception throws won't save you from null > pointer or garbage pointer dereferences.You can catch the null pointer and garbage pointer dereferences with a signal handler (in Linux land, at least), and then invoke your direct reporting mechanism with that. Is the concern that some of the other LLVM clients don't have signal handling? Robert