aborting on invalid code

Besides invalid IR, codegen also uses abort and assert when it
encounters valid and Verifier-clean IR that uses features that
codegen does not suport, due to missing functionality (e.g. i1024)
or due to target-specific limitations (e.g. x86_f80 on non-x86
targets).

Currently there no way to recover if the IR contains some
construct that codegen can't handle. This is unfortunate for some
applications.

Dan

[...] Sending invalid
code into the backend is violating a very important invariant in the
API. I don't see how it would be any different then passing in a null
pointer or garbage pointer into an API that would then bus error.

Besides invalid IR, codegen also uses abort and assert when it
encounters valid and Verifier-clean IR that uses features that
codegen does not suport, due to missing functionality (e.g. i1024)
or due to target-specific limitations (e.g. x86_f80 on non-x86
targets).

There are also some cases with inline asm that do the same thing.

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.

-Chris

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?

--Vikram
Associate Professor, Computer Science
University of Illinois at Urbana-Champaign
http://llvm.org/~vadve

And when that mechanism will exist, it'll be also completely safe to
delete the Module,
and call llvm::shutdown to prevent memory leaks as well, right? :wink:

And if somebody really wants exceptions, he could use them without
adding exceptions to LLVM itself.
He could wrap the call to LLVM that can fail in a try{} catch{}, and set
the failure hook to throw an exception.
That would get properly propagated back up to the catch, even if LLVM
itself is compiled without exceptions, and then
in the catch the Module can be deleted, and llvm::shutdown called. Would
that work?

Best regards,
--Edwin

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

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

Garbage/dangling pointers can corrupt memory, they don't always trap. C just isn't a safe programming language (though there are many interesting research projects that can help).

-Chris

Exceptions have a high cost in terms of code size, binary size, and
even a bit of execution time.

I agree. I think the client should be allowed to choose whether to compile these in or not. At the LLVM library level, this may have to be compile-time selected (which could be a bit ugly but should not be too bad) to avoid the code size problem.

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.

I understand that -- you're not making the client's life easy, you're just making it possible.

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?

Garbage/dangling pointers can corrupt memory, they don't always trap.
C just isn't a safe programming language (though there are many
interesting research projects that can help).

Yes, but that's a case that LLVM would not do any error reporting anyway. In any case, where it would otherwise report an error, it seems to me you could give the client the *option* to handle the signal and throw an exception, if needed, and then field the exception.