[LLVMdev] Upstreaming PNaCl's IR simplification passes

[Alon Zakai]

To add to what Mark mentioned about Emscripten's new backend [1] using the
PNaCl passes: It made writing the backend much easier than it otherwise
would have been, given our requirements - we are an 'odd' target in that we
want to transform LLVM IR into JavaScript, then run it through our existing
external JavaScript optimizer tool, which does very JavaScript-specific
optimizations (on a JavaScript AST which is the natural form for us), and
for that reason we don't use the common backend codegen path. Basically the
PNaCl simplification passes convert LLVM IR into a smaller and simpler
subset of LLVM IR, which makes writing a backend that processes LLVM IR
more convenient.

I think there are other use cases as well that could benefit from these
passes being upstream. While typically a backend would want to use the
common codegen to get register allocation and so forth, there are
situations where you just want to transform LLVM IR into something else.
For example in a university course you could teach people compiler
optimizations using LLVM IR, then have them write a tiny backend that
compiles that IR into a familiar language (Python, Java, anything else that
they already know) to execute it (lli also works of course, but this might
feel more "concrete" for the students, and they would learn more I
suspect). Writing that backend in a way that processes LLVM IR means you
only need them to understand LLVM IR and not anything about the selection
DAG etc. Also, there are situations where performance is really not a
concern, like someone writing a backend for a little VM they invented for
fun and just want to execute small amounts of C code on it - for example
this happened with the DCPU-16 spec, and people made an LLVM backend for it.

In summary, I think the shared thing in these examples is that LLVM IR is
very nice to work with, and there are some situations where you're using it
and you have a reason to convert it into something else, and you want to do
that in as _simple_ a way as possible as opposed to generating the most
_optimal_ results. The PNaCl IR simplification passes are in my opinion a
big help there.

- Alon

[1] https://github.com/kripken/emscripten/wiki/LLVM-Backend



On Tue, Mar 4, 2014 at 1:04 PM, Mark Seaborn <mseaborn at chromium.org> wrote:

> The PNaCl project has implemented various IR simplification passes that
> simplify LLVM IR by lowering complex features to simpler features.  We'd
> like to upstream some of these IR passes to LLVM.  We'd like to explore if
> this acceptable, and if so, how we should go about doing this.
>
> The immediate reason is that Emscripten is reusing PNaCl's IR passes for
> its new "fastcomp" backend [1].  It would be really useful if PNaCl and
> Emscripten could collaborate via upstream LLVM rather than a branch.
>
> Some background:  There are two related use cases for these IR
> simplification passes:
>
>  1) Simplifying the task of writing a new LLVM backend.  This is
> Emscripten's use case.  The IR simplification passes reduce the number of
> cases a backend has to handle, so they would be useful for anyone else
> creating a new backend.
>
>  2) Using a subset of LLVM IR as a stable distribution format for portable
> executables.  This is PNaCl's use case.  PNaCl's IR subset omits various
> complex IR features, which we lower using the IR simplification passes [2].
>  Renderscript is an example of another project that uses IR as a stable
> distribution format, though I think currently Renderscript is not
> subsetting IR much.
>
> Some examples of PNaCl's IR simplification passes are:
>
>  * Calling conventions lowering:  ExpandVarArgs and ExpandByVal lower
> varargs and by-value argument passing respectively.  They would be useful
> for any backend that doesn't want to implement varargs or by-value calling
> conventions.
>
>  * Instruction-level lowering:
>     * ExpandStructRegs splits up struct values into scalars, removing the
> "insertvalue" and "extractvalue" instructions.
>     * PromoteIntegers legalizes integer types (e.g. i30 is converted to
> i32).
>
>  * Module-level lowering:  This implements, at the IR level, functionality
> that is traditionally provided by "ld".  e.g. ExpandCtors lowers
> llvm.global_ctors to the __init_array_start and __init_array_end symbols
> that are used by C libraries at startup.
>
> PNaCl's IR simplification passes are modular -- most are independent of
> each other -- so they allow projects to pick and choose which IR features
> to support and which to pre-lower.  The modularity of these passes makes
> them low-maintenance and easy to write targeted tests for.
>
> The code for these passes can be found here:
>
> https://chromium.googlesource.com/native_client/pnacl-llvm/+/master/lib/Transforms/NaCl/
>
> There seems to be plenty of precedent for IR-to-IR lowering passes -- LLVM
> already contains passes such as LowerInvoke, LowerSwitch and LowerAtomic.
>
> The PNaCl team (which I'm a member of) is happy to take on the work of
> maintaining this code, such as updating it as LLVM IR evolves and doing
> code reviews.  We would upstream this gradually, pass by pass, so the
> changes would be manageable.
>
> Cheers,
> Mark
>
> [1] https://github.com/kripken/emscripten/wiki/LLVM-Backend
> [2] https://groups.google.com/forum/#!topic/llvm-dev/lk6dZzwW0ls - PNaCl
> Bitcode reference manual
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140304/c1214e5f/attachment.html>