[llvm-dev] Managed Languages BOF @ Dev Meeting
David Chisnall via llvm-dev
llvm-dev at lists.llvm.org
Sun Oct 18 04:53:02 PDT 2015
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.
More information about the llvm-dev