[llvm-dev] Managed Languages BOF @ Dev Meeting

[David Chisnall via llvm-dev]

I won’t be able to attend, but I’d be interested in hearing if any conclusions are reached on several of these topics:

> On 16 Oct 2015, at 21:27, Joe Ranieri via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> - Dealing with the explosion of basic blocks that come up with
> languages where almost every function call, implicit and explicit, can
> raise exceptions.

This also relates to non-call exceptions.  There was a proposal a few years ago to adopt a model a bit closer to WHRIL’s exception regions, where the unwind destination would become a property of the basic block, not the call site (this also maps fairly closely to the underlying implementation, which deals with PC-ranges).  You would need to split blocks in places to ensure that every used value in the unwind target is live on entry to a block that can unwind to it, but that should still reduce the basic block explosion.

> - Proper ABI implementation without reimplementing Clang's
> TargetInfo.cpp or embedding Clang.

Although the implementation is a bit hairy, GCC’s JIT interfaces are a lot cleaner in this respect, as they deal with C types.

I’m not opposed to having to embed a chunk of clang (clang itself isn’t that huge, and in a shared-library build the size is easily amortised), but it would be very nice to have some of this exposed via stable interfaces.  I believe that Apple folks have done some work in this direction for Swift - perhaps they could be persuaded (either as part of, or separately from, the open sourcing of Swift) to put some work into a stable library interface for external consumers?

> - The issue of knowing what the canonical IR is to begin with and then
> how to deal with the differences.

This is largely a documentation issue.  Various passes all have different notions of canonical forms for various constructs in their input and output and these are all undocumented.

David