[LLVMdev] Upstreaming PNaCl's IR simplification passes

[Eli Bendersky]

<snip>

>
>>> 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.
>>>
>>
>> While this is appreciated, the PNaCl team should work to much more
>> actively contribute to the core of LLVM if it wants to be trusted to
>> maintain this code.
>>
>
> Is eliben still on the PNaCl team? (e.g. <
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-June/063010.html>)
>

Technically, no. While I'm still collaborating with the PNaCl team on some
tasks, I'm not likely to be maintaining these passes as part of my day job
(beyond the usual upstream gardening I do from time to time).

That said, personally I think these passes are very useful in upstream
LLVM. For example, juts recently I found the constant-expr elimination
extremely handy in a completely PNaCl-unrelated out-of-tree project I'm
working on. Having this code in upstream LLVM would be wonderful --
otherwise I just maintain my own copy. Not only the simplification passes
make LLVM IR more palatable for non-traditional backends, they also strike
into the very important conundrum of whether LLVM IR is, or can be, target
independent. PNaCl is an interesting proof of concept that LLVM IR can
indeed, under some circumstances, be useful as a target-indepentent IR. I
think this opens up many interesting opportunities for LLVM.

As for the maintenance cost... the passes are really quite simple in
essence. Moreover, if two very significant projects rely on them (PNaCl is
officially released in Chrome, Emscripten is extremely popular too), it
seems unlikely to me that they will bit-rot.

The detailed technical concerns are very interesting, of course (for
example, where it's most proper to do integer legalization). These should
definitely be discussed in detail on a case-by-case basis, but I don't see
them as a strong reason not to add this to LLVM at all.

Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140304/952750f8/attachment.html>