[LLVMdev] Upstreaming PNaCl's IR simplification passes

[Alon Zakai]

Sorry to reply to myself, I thought of something else I should have
mentioned before. Emscripten hopes to eventually upstream its JavaScript
backend, if there is interest. It's a work in progress and far from ready
for that right now, and there are probably lots of issues to figure out
regarding that (again, far too early to get into detail), but one thing
will be the dependence of the backend on the PNaCl IR simplification passes
- I guess if they are not upstream at that point, we'd have to figure
things out then.

- Alon



On Tue, Mar 4, 2014 at 2:25 PM, Alon Zakai <alonzakai at gmail.com> wrote:

> 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/fa8f31fa/attachment.html>