[LLVMdev] Upstreaming PNaCl's IR simplification passes

[Joshua Cranmer 🐧]

On 3/4/2014 5:18 PM, Chandler Carruth wrote:
>
> On Tue, Mar 4, 2014 at 3:11 PM, Sean Silva <chisophugis at gmail.com 
> <mailto:chisophugis at gmail.com>> wrote:
>
>     On Tue, Mar 4, 2014 at 4:04 PM, Mark Seaborn
>     <mseaborn at chromium.org <mailto: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.
>
>
>     FWIW, this sounds to me like a sufficiently compelling use case to
>     support getting this in-tree.
>
>
> Just in case it gets lost in my longer reply, I want to emphasize that 
> if these will be used to simplify the in-tree backends and those 
> backend maintainers are on board, then I am *totally* in favor of this 
> going into the tree. My concerns are heavily based on the fact that as 
> proposed, none of that seems likely to happen.

Framing the problem differently, what I see is this:
PNaCl (and, by implication elsewhere in the thread, Emscripten and a 
hypothetical new C backend or MSIL backend) are basically backends that 
don't go through the SelectionDAG mechanism and largely bypass the 
current backend logic that legalizes IR for a backend. The problem is 
that basically all the targets in the LLVM tree use SelectionDAG and 
associated mechanisms. Arguably the NVPTX backend might benefit from 
such an approach (since it ultimately needs to allocate virtual 
registers), but I've never developed any backends, so I don't know what 
the tradeoffs are there. In any case, it's extremely unlikely that code 
which is only useful for IR-based backends instead of SelectionDAG-based 
backends could be useful for any in-tree targets.

In that frame of model, though, I do see a potential compromise: instead 
of proposing virtual clones of what is essentially IR legalization for 
an IR-based backend, why not attempt to generalize the current 
legalization logic to work for IR-based backends instead of only 
SelectionDAG-based backends?

-- 
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

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