[LLVMdev] Exception Handling Proposal - Second round

[Andrew Trick]

On May 17, 2011, at 3:16 PM, Renato Golin wrote:
> 
> F6. Some instructions (such as divide in Java) can throw exceptions
> without an explicit dispatch mechanism


This sounds like something that came out of a brainstorming session then snuck into the project requirements when it's really a separate issue. I think you can safely ignore it.

Implicit exceptions at the Java bytecode level are independent of how the compiler models trapping instructions. An optimizing compiler will lower bytecode into an IR with explicit control flow--this does not inhibit optimization, it facilitates optimization. Note that branches are no more a barrier to optimization than implicit exceptions. The difference is that an effective optimization pass already needs to handle branches regardless of the source language or whether compiling with exceptions enabled. It may currently be a weak aspect of a few LLVM passes, but that's much easier to fix than modifying the IR.

Some code generators may emit exceptional control flow as a trapping instruction. This obviously requires runtime support but is otherwise language independent. This is best done as late as possible (think instruction scheduling) in a target specific manner. In practice, I've only seen it used for implicit null checks to shave a cycle off some loads and squeeze a tiny amount of performance out of benchmarks. In fact, hardware support for *nontrapping* loads from page zero plus safe speculation would work much better. In my opinion, implicit null checks are not worth the giant support overhead typically caused by a runtime that tries to catch SIGSEGV. I wouldn't expect a user-space signal handler to be used for integer divides, where there's no performance benefit.

-Andy