llvm dev - Oct 2015 - Managed Languages BOF @ Dev Meeting

Sanjoy, Joseph, and I will be hosting a BoF on using LLVM to build 
compilers for managed languages.  We're curious to hear who's planning 
on attending and what topics you'd like to hear about. Depending on the 
expected audience, we're happy to do anything between a rough "what to 
expect getting started" to a down in the weeds working session on 
relevant optimization or ABI related topics.  If you're planning on 
attending, please let us know.  If you have particular topics you'd like 
to hear about or discuss, please reply to this thread.

The major areas we've thought of include:
- High level architectures for successful projects: debuggable 
architectures, working with the community, etc..
- Dealing w/ABI requirements like calling conventions, exceptions, 
patchable calls, Inline caches, frame inspection, and deoptimization
- Lowering/compilation strategies for high level languages
- Differences in canonical IR from traditional C code and resulting 
optimization challenges

Philip


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151015/dda91e73/attachment.html>

On Thu, Oct 15, 2015 at 8:58 PM, Philip Reames via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Sanjoy, Joseph, and I will be hosting a BoF on using LLVM to build
compilers
> for managed languages.  We're curious to hear who's planning on
attending
> and what topics you'd like to hear about.  Depending on the expected
> audience, we're happy to do anything between a rough "what to
expect getting
> started" to a down in the weeds working session on relevant
optimization or
> ABI related topics.  If you're planning on attending, please let us
know.
> If you have particular topics you'd like to hear about or discuss,
please
> reply to this thread.
>
> The major areas we've thought of include:
> - High level architectures for successful projects: debuggable
> architectures, working with the community, etc..
> - Dealing w/ABI requirements like calling conventions, exceptions,
patchable
> calls, Inline caches, frame inspection, and deoptimization
> - Lowering/compilation strategies for high level languages
> - Differences in canonical IR from traditional C code and resulting
> optimization challenges
>
> Philip
I'm planning on attending. You've mentioned some of these, but
specific topics of interest for me include:
- Dealing with the explosion of basic blocks that come up with
languages where almost every function call, implicit and explicit, can
raise exceptions.
- Proper ABI implementation without reimplementing Clang's
TargetInfo.cpp or embedding Clang.
- The issue of knowing what the canonical IR is to begin with and then
how to deal with the differences.
- Preserving correct semantics of language specific constructs without
hindering optimizations.

-- Joe Ranieri

I'm planning to attend. I'm generally interested in hearing about use
cases
for LLVM's JIT infrastructure, and looking for opportunities to improve our
support for them.

Cheers,
Lang.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151016/19b2f802/attachment.html>

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

Hi,

I'm planning to attend. I'm interested in hearing about efforts to
add/enhance middle-end and back-end optimizations to LLVM. For example,
will be there something like Polly but more integrated to LLVM and not only
limited to SCoPs?

Best,
Dounia

On Thu, Oct 15, 2015 at 7:58 PM, Philip Reames via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Sanjoy, Joseph, and I will be hosting a BoF on using LLVM to build
> compilers for managed languages.  We're curious to hear who's
planning on
> attending and what topics you'd like to hear about.  Depending on the
> expected audience, we're happy to do anything between a rough
"what to
> expect getting started" to a down in the weeds working session on
relevant
> optimization or ABI related topics.  If you're planning on attending,
> please let us know.  If you have particular topics you'd like to hear
about
> or discuss, please reply to this thread.
>
> The major areas we've thought of include:
> - High level architectures for successful projects: debuggable
> architectures, working with the community, etc..
> - Dealing w/ABI requirements like calling conventions, exceptions,
> patchable calls, Inline caches, frame inspection, and deoptimization
> - Lowering/compilation strategies for high level languages
> - Differences in canonical IR from traditional C code and resulting
> optimization challenges
>
> Philip
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>

-- 
Dounia KHALDI
Postdoctoral Fellow
University of Houston
Department of Computer Science
501 Philip G. Hoffman Hall
Houston, TX  77204-3010
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151018/ecca2c3a/attachment.html>

On Oct 16, 2015, at 1:27 PM, Joe Ranieri via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> I'm planning on attending. You've mentioned some of these, but
> specific topics of interest for me include:
> - Dealing with the explosion of basic blocks that come up with
> languages where almost every function call, implicit and explicit, can
> raise exceptions.
I saw this come up in a recent discussion about LLILC.  One simple way to do
this is to introduce a new intrinsic, like “llvm.nullcheck(x)” which
symbolically represents the null check and bail out in one instruction - instead
of the fully elaborated basic block representation (which slows everything down
by increasing the height of the CFG).  These null checks can be optimized away
through standard techniques, and any remaining ones expanded out to LLVM IR
before codegen, or as part of lowering to MachineInstrs.

-Chris