[LLVMdev] Requirements for the EH representation

[Renato Golin]

On 14 April 2011 03:43, John McCall <rjmccall at apple.com> wrote:
> If you want to volunteer to keep track of the discussion on the wiki, I
> think that would be great.  I don't think we're going to hold the
> discussion on the wiki, though.

Of course. But all our discussions last year got lost and the context
is gone. To get the context back one would have to re-read *all*
emails, which is a long way to go.

I can keep track on the wiki. no problems, but I need everyone
interested in the subject to constantly validate it, as I plan to
transform that into a design document that we must follow when
considering changing the IR, not only for EH, since EH touches
everything.

Ultimately, the goals and design decisions should go in its own
document and the IR changes in LangRef.


> Also, what you've listed as "Areas to Consider" are explicitly things
> I *don't* want to consider immediately.  Those are interesting
> questions, but they're separate questions, and we should settle
> on these basic requirements first.

We need at least two points to draw a line. One in the near future and
one in the far future.

The former fixes our problems, but that's not enough. We need the
latter to steer us in the right direction and not get lost again.

As you very well know, exception handling cannot be underestimated. We
need everyone to agree one near and far goals to avoid this topic
showing up every year.


> I personally don't;  I think we should aim to get
> the IR design good enough to support crazy resumptive languages
> with crazy custom unwinding schemes.  But I need to know what range
> of problems we're willing to consider solving before I can usefully weigh
> different solutions.

Thus, long term plan. ;)

Whatever quick fix we do now will only postpone the real issue. The IR
cannot represent many of the exception cases we came up last year and
the (somewhat radical) changes we proposed could, but every time we
got to a conclusion, someone else would come and say: "this doesn't
work for <language>" or "consider <this> case" and we were back to
square one.

We need a stable place to list *all* languages, *all* cases and
consider *all* ABI constraints (as far as possible, obviously), before
we start taking strong design decisions. That's probably the only
reason to have a wiki in the first place.

cheers,
--renato