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.
>
> Definitions
> ==========>
> A "region" is defined as a section of code where, if an exception
> is thrown
> anywhere within that section, control is passed to code that will
> handle the
> exception (called a "landing pad"). The code which handles the
> specific
> exception is unique to that region. For example, "invoke A" and
> "invoke B" are
> within the same region (X):
>
>
> Region X
> ..........................................
> : :
> : .----------. .----------. :
> : | invoke A | | invoke B | :
> : `----------' `----------' :
> : / | / | :
> : normal | normal | :
> ..........................................
> | |
> | v
> | .------------------.
> | | B's cleanup code |
> | `------------------'
> | |
> `---------------------'
> |
> v
> .-----------------------.
> | A's cleanup code |
> | dispatch for region X |
> `-----------------------'
> |
> .-----------------------------.
> | | | |
> v v v v
> .----. .----. .----. .--------.
> | C1 | | C2 | ... | Cn | | resume |
>
>
> C1, C2, ..., Cn are the catches for the exception thrown. If none
> of the
> catches' types match the type of the exception thrown, control
> passes to the
> "resume".
>
> Notice that even though invokes A and B are in the same region,
> they do not
> necessarily jump to the same basic block when an exception occurs.
>
>
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>