<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 3/4/2014 5:18 PM, Chandler Carruth
wrote:<br>
</div>
<blockquote
cite="mid:CAGCO0KgbpZ9g2NDVhZYzTkPdjohgo2SSMcL+Zo1AQh5+Mqv12Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Mar 4, 2014 at 3:11 PM, Sean
Silva <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">On Tue, Mar 4, 2014 at 4:04 PM, Mark Seaborn
<span dir="ltr"><<a moz-do-not-send="true"
href="mailto:mseaborn@chromium.org" target="_blank">mseaborn@chromium.org</a>></span>
wrote:<br>
</div>
<div class="">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Some background: There are two related use
cases for these IR simplification passes:</div>
<div><br>
</div>
<div> 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.</div>
</div>
</blockquote>
<div><br>
</div>
</div>
<div>FWIW, this sounds to me like a sufficiently
compelling use case to support getting this in-tree.</div>
</blockquote>
</div>
<br>
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.</div>
</div>
</blockquote>
<br>
Framing the problem differently, what I see is this:<br>
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.<br>
<br>
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?<br>
<pre class="moz-signature" cols="72">--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist</pre>
</body>
</html>