<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><snip> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">

<div class="gmail_quote"><div class=""></div><div class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div dir="ltr"><div><br></div><div>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.</div>



</div></blockquote><div><br></div></div><div>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.</div></div></div></div>


</blockquote><div><br></div></div><div>Is eliben still on the PNaCl team? (e.g. <<a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-June/063010.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-June/063010.html</a>>)</div>

</div></div></div></blockquote><div><br></div><div>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).</div>

<div><br></div><div>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.</div>

<div><br></div><div>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.</div>

<div><br></div><div>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.</div>

<div><br></div><div>Eli</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div></div></div>