[PATCH] D17778: TypedError for recoverable error handling

[Owen Anderson via llvm-commits]

resistor added a comment.

Hi Lang,

I want to ask what I feel is an important high-level question here:  how does this approach differ, fundamentally, from exceptions, and why should we go down the route of building our own error handling scheme rather than “just” adopting exceptions?

To answer my own question, my impression is that your proposed scheme is functionally similar to exceptions, with the major deviation of being opt-in rather than opt-out.  While opt-in is intellectually appealing at first glance, I’m not convinced that it is actually the best solution to some of the problems at play here.  In particular, an opt-in scheme will require threading the error-handling type system through many layers of generic and/or boilerplate code in order to allow various callbacks in target backends to report errors properly.

As a concrete example, every backend under the sun has some degree of implicit contract between the backend and the frontend regarding supported IR constructs.  This can be as “simple” as ABI lowering and intrinsic names for a typical CPU target, but can be far more complex for targets with non-traditional execution models.  In either case, it seems very desirable for the target in the abstract, and instruction selection in particular, to be able to report violations of this contract via the error reporting mechanism.  However, to do some in the context of SelectionDAG or FastISel (and I see no particular reason why GlobalISel will be particularly different) would require threading error checking through vast swaths of code both in the instruction selection infrastructure and in the callbacks for the targets themselves.  Moreover, instruction selection tends to be a performance sensitive component of the compiler, which argues in favor of exceptions which are, at least notionally, zero-cost.

I’m not claiming here to have a global optimally solution to the problem, and I emphatically do want to see LLVM be better behaved about error handling in general.  But it’s not clear to me exactly where the right cost/benefit tradeoff lies in terms of error handling technologies.

—Owen


Repository:
  rL LLVM

http://reviews.llvm.org/D17778