[llvm-dev] Managed Languages BOF @ Dev Meeting
Sanjoy Das via llvm-dev
llvm-dev at lists.llvm.org
Sun Oct 18 15:08:28 PDT 2015
> 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.
Supporting only basic block level granularity for "try ranges" may not
be sufficient for Java -- if a basic block has more than one null check
in it then throwing the NullPtrException for the first null check (if
it fails) is semantically different from throwing the NullPtrException
for the second null check (the constructed exceptions will have
different stack traces attached to them, for instance ). So we'd
have to do repeat the null checks in the unwind block, like
superblock: # unwinds to unwind_block
;; either ptr_a is null or ptr_b is null
if (ptr_a == null)
throw_nullptrexception(bci = 42)
else ;; if (ptr_b == null)
throw_nullptrexception(bci = 43)
So the code explosion problem still exists (in unwind_block), and
we've duplicated a bunch of code.
Having said that, I'd love to take a look at the proposal that was
made -- will it be easy for you to dig up a link?
: there is a "hot exception" optimization that some JVMs can do
that may allow us to get around this
but that's an _optimization_ that Java programmers should be able to
>> - 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
> 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.
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
More information about the llvm-dev