LLVMdev Digest, Vol 77, Issue 37

Bill,
        I am still trying to figure out what you mean by "region", is it merely a conceptual hold-over
from the high level language definition(s) of exceptions, or are you attempting to introduce
some new construct into the LLVM IR control-flow graph.....

I see (at least) two alternatives for lowering exception regions

1) identify a "region" as you say as being an area of code from which any thrown exception
gets handled by some common handler code. This seems to require adding a new capability
to the control-flow graph. Along with that the proposal would have to include precise semantics
of what the limits to optimization are within and across the boundary of that region, this would
then probably necessitate adding (lots of?) logic to all existing analyzers and optimizers.

2) identify with each instruction that can generate an exception -- (be that a numerical instruction
that could fault, an allocate instruction that could exhaust memory, a memory reference that could
be invalid, or an invoke from which an exception could be propagated out of, etc, etc, etc) -- the
alternate location to go to for a fault/throw rather than sequential fall thru execution for that particular
instruction. This seems to require adding a new capability to each instruction that can fault or
propagate. Hopefully the optimization semantics of such enhanced instructions would be identical
to those existing control-flow controlling instructions (conditional jumps, switch cases, computed
gotos, etc), and

both of these options seem to require changes/enhancements, but which of them allows for the
rest of the analysis and optimization phases of LLVM to continue with the least amount of
change ?, or with the least objectionable change ?, or with the least complicating and least
counter-intuitive change ?

option (2) is what analysis and optimization algorithms require, namely complete and exact
control flow and data flow information.

option (1) is what your mental run-time model wants, namely a fairly simple match-up with the
original source code, which also happens to match-up with an existing ABI that is also a fairly
simple match-up with the original source code.

sincerely,
Peter Lawrence.

Hi Peter,

Sorry for the late response.

The idea of a “region” is more a conceptual hold-over as you say. The only limitations it places upon optimizations are those which currently exist, because the “invoke” is a terminating instruction.

I agree that, when we go to a more general system for exception handling – whether it be adoring a basic block with unwind information or adorning individual instructions with them –, all of the things you pointed out will have to be addressed. Any proposal which makes optimizations more difficult simply won’t work. But we also have to make sure we don’t break the semantics of the program by moving an instruction out of one region and into another. I haven’t given a lot of thought to a solution for this, so I don’t have much more to say on the topic.

The proposal I sent out isn’t meant to address the more general question. But it is meant to be a step towards that goal. The concept of a “region” (however that may be defined, if at all) shouldn’t detract from the main goal of the rewrite. It’s mostly just a good way to understand where the proposal came from.

-bw