Exception Handling Proposal, Second round Re: LLVMdev Digest, Vol 83, Issue 30

Renato,
I agree with what Andrew said, but would have worded it differently. All optimizers (that
I am aware of) require explicit control flow, so things like exception-throwing-divide-instructions
need to be converted into IR that are Block-Terminators. Andrew was explaining how this is
a non-performance issue in practice, I am explaining how this is a requirement of how optimizer
are implemented in practice.

-Peter Lawrence.

Renato,
I agree with what Andrew said, but would have worded it differently. All optimizers (that
I am aware of) require explicit control flow, so things like exception-throwing-divide-instructions
need to be converted into IR that are Block-Terminators. Andrew was explaining how this is
a non-performance issue in practice, I am explaining how this is a requirement of how optimizer
are implemented in practice.

-Peter Lawrence.

Thanks for the clarification, Peter. I was trying to convey two main points:

  1. Optimizers require explicit control flow, which is not a limitation because it’s easy to optimize across branches (calls and merges are hard to handle).
  2. Codegen can convert control flow to trapping instructions, but it’s seldom worthwhile.

-Andy

Andy,
I think we are in complete agreement !

My admittedly superficial reading of the “Structured Exception Handling” patent lead me to believe that
non-connected control-flow was part of that design, and I am always worrying that folks are trying to leverage
off that design, so I am always trying to emphasize that that concept is incompatible with modern optimization
theory and practice.

-Peter.