RFC: Exception Handling Proposal Revised

responses to the Exception Handling Proposal are "all over the map", including at least....

1. what are the semantics of the various high level languages, and how are these constructs
to be lowered into an IR

2. what should the IR be

3. what should the final output code format and layout be, and to what extent can/should
this be compatible with any existing runtime environments and ABIs

4. what exception specific optimizations can be done on this IR

5. what "zero cost when no exception is thrown" degree of achievement is possible

concerning #2, I have a question relative to the "Proposal", is a "region" a basic block or not ?

I ask because it is not clear at least to me what the proposer intended, and it is crucial...

All the existing analysis and optimization phases are designed to operate on basic blocks,
and the definition of a basic block is not flexible, you cannot leave a basic block from the
middle of it (if you can then for example a register allocator cannot know where within
a basic block spill/fill code for global registers can be inserted because you cannot know
if any specific location within the block will actually be executed before you "leave"
from the block).

I believe other folks have already tried to raise this question, but when formulated in terms of
phi nodes or what ever neither the question nor the answer are as clear as when it is formulated
in terms of basic blocks.....

sincerely,
Peter Lawrence.

Hi Peter,

responses to the Exception Handling Proposal are "all over the map",
including at least....

1. what are the semantics of the various high level languages, and
how are these constructs
to be lowered into an IR

2. what should the IR be

3. what should the final output code format and layout be, and to
what extent can/should
this be compatible with any existing runtime environments and ABIs

4. what exception specific optimizations can be done on this IR

5. what "zero cost when no exception is thrown" degree of achievement
is possible

concerning #2, I have a question relative to the "Proposal", is a
"region" a basic block or not ?

No. Or at least not how I defined it in my proposal. The concept of a region has become less important with the revised proposal. With that, it's more of a conceptual idea rather than a physical entity that exists within the IR itself.

I ask because it is not clear at least to me what the proposer
intended, and it is crucial...

All the existing analysis and optimization phases are designed to
operate on basic blocks,
and the definition of a basic block is not flexible, you cannot leave
a basic block from the
middle of it (if you can then for example a register allocator cannot
know where within
a basic block spill/fill code for global registers can be inserted
because you cannot know
if any specific location within the block will actually be executed
before you "leave"
from the block).

Exactly, and I don't want to change that right now. However, if you read Chris's notes, you'll notice that this is something which we want to address in the future. It becomes very inflexible to support languages where other native IR instructions may throw by requiring only the terminator to throw. E.g., take this code, where if any of the instructions throw, we want to unwind to `lpad':

bb:
  %x = fadd f32 %a, %b
  %y = fdiv f32 %x, %c
  %z = fmul f32 %y, %d
...

lpad:
  ; Handle the exception thrown

If we wanted to support the fact that all of these instructions could throw (say, in Java or C# or other such language), we would currently have to make each of them a terminator whose unwind edge jumps to the correct landing pad:

bb:
  %x = fadd f32 %a, %b
     to %bb1 unwinds to %lpad
bb1:
  %y = fdiv f32 %x, %c
     to %bb2 unwinds to %lpad
bb2:
  %z = fmul f32 %y, %d
     to %bb3 unwinds to %lpad
lpad:
  ; Handle the exception thrown

(This is a totally made up syntax, but you get the picture.) It's just very, very ugly and inflexible. I.e., optimizations within this chunk of code are pretty much out of the question.

I believe other folks have already tried to raise this question, but
when formulated in terms of
phi nodes or what ever neither the question nor the answer are as
clear as when it is formulated
in terms of basic blocks.....

Yes, I think we all have the same concerns. I hope this clears up the issue a bit. :slight_smile:

-bw