[LLVMdev] How to handle divide-by-zero exception?

[Nick Lewycky]

Talin wrote:
> Currently it states in the language manual that the results of division 
> by zero are undefined. However, I'm curious as to how you would normally 
> handle either divide by zero or other "hardware" exceptions (null 
> pointer dereference and so on) and turn them into LLVM exceptions.

Ultimately, what we'd like to do is attach a bit to each instruction 
which specifies whether it may trap. If something happens (like an 
invalid pointer dereference or divide by zero), it would have to become 
an LLVM 'exception' if the bit is true, or else execute undefined 
behaviour. The goal being to allow language frontends that want to trap 
(like Java) to set the bit, and others (like C) can clear it on all 
instructions and never pay any performance penalty.

http://nondot.org/sabre/LLVMNotes/ExceptionHandlingChanges.txt

> It seems to me that you would need some way to set up the unwind labels 
> beforehand, just like you do for the invoke instruction. For the 
> specific case of divide by zero, I can imagine an optional unwind label 
> parameter for the divide instruction, however that won't work too well 
> for other kinds of exceptions since any load or store instruction could 
> potentially produce them.

The major problem is how you define "dominance" once you've modified the 
concept of a basic block to allow edges coming out the middle instead of 
the bottom. We've had an extensive thread on this in the past where the 
consensus was:

  * given a block A with an 'unwinds to' label to B:
   - A is a predecessor to B (B is a successor of A)
   - for the dominator tree, A and B are treated as if they shared the 
same predecessor.
  * we permit 'unwinds to' on the entry block, even though this means 
that there is no singular dominator root to the function. The domtree 
calculations already support this, though it means that you can't just 
add an AllocaInst to the entry block and the load/store it in any 
arbitrary block in the problem (if it were only reachable from the 
'unwinds to' edge of the entry block).

There already exists a branch where this work is in progress, named 
"llvm-non-call-eh". I haven't been able to give it as much attention as 
it deserves, and would appreciate any help working on it.

Nick Lewycky