[LLVMdev] LLVM EH Regions?

[Bill Wendling]

On Dec 2, 2010, at 1:18 PM, Peter Lawrence wrote:

> 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.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101222/f833f6a0/attachment.html>