<div dir="ltr">All,<div><br></div><div>Thanks for the insights and thoughtful suggestions ventured here. If I may, I wanted to summarize the discussion so far, add a few small points, and suggest a step forward. I'll begin by a recap and add a few points.<br>
</div>
<div><br></div><div>First, the central objections to placing these passes in-tree seem to center mostly around additional complexity in the code base and lack of testing, etc. As several have pointed out, the complexity of the passes themselves is very low, and in all cases is intended to *reduce* the complexity of the IR surface exposed to consumers of the bitcode. We believe, as others on this list have expressed, a smaller IR surface to understand and implement enables new users of the LLVM infrastructure.</div>
<div><br></div><div>Second, there are teams that are already using LLVM today for non-traditional applications outside the tree, in products that their respective companies support. For instance, LLVM is already being used efforts to make native code in the web something real. To plug the idea we're all pursuing there -- bringing native code to the web increases the reach of developers (reminder: there are now over a billion web browser users out there, and the number is growing fast) and has demonstrated advantages for deployment and update. To name one of the projects pursuing this, Mozilla's Emscripten effort has a JavaScript backend in very active development, and Alon has stated here that he would like to upstream his work eventually. And of course, my own team has been using LLVM since the beginning and have released PNaCl, based on LLVM bitcode, as a feature available in Chrome.</div>
<div><br></div><div>Third, an objection was raised that, if these simplifications are useful, they should be used by in-tree backends. As someone noted, some of the transformations are more like legalizations for backends, and I would imagine that they would be more useful for some than for others (e.g, GEP simplifications may be a better match for a RISC like MIPS than for x86). I propose we get specific about the passes and see which backend maintainers think they might profit from using them. But even if other in-tree backends don't want to use the passes, there seems to be a class of backend that is not yet in the tree that does want to use similar transformations. Or simplifying the IR in these ways will produce more such users.</div>
<div><br></div><div>Fourth, an objection came up that these passes were similar to ones that used to be in LLVM, but were removed. Sometimes ideas just have their right time, and we seem to have found more users than just the C backend.</div>
<div><br></div><div>Last, some have objected that the passes bake in C/C++/ELF runtime library conventions such as baking in init/fini/ctor/dtor processing and libc startup/teardown. The passes Mark described are not monolithic, and we would be happy to share any or all of them individually if such transformations aren't deemed interesting.</div>
<div><br></div><div>Now to the steps ahead: I propose Mark sends some patches for the simpler passes out to let you, our esteemed colleagues, discuss them concretely. As several have noted, these patches could be interesting to them, and it seems reasonable to pass them along here for the potential benefit of those folks. Also as Alon noted, it would be nice to have this underway before he comes back with his backend work. Your thoughts are respectfully solicited.</div>
<div><br></div><div>Cheers,</div><div><br></div><div>David</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Mar 5, 2014 at 4:53 PM, James Courtier-Dutton <span dir="ltr"><<a href="mailto:james.dutton@gmail.com" target="_blank">james.dutton@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>><br>
> Just in case it gets lost in my longer reply, I want to emphasize that if<br>
> these will be used to simplify the in-tree backends and those backend<br>
> maintainers are on board, then I am *totally* in favor of this going into<br>
> the tree. My concerns are heavily based on the fact that as proposed, none<br>
> of that seems likely to happen.<br>
><br>
><br>
> Framing the problem differently, what I see is this:<br>
> PNaCl (and, by implication elsewhere in the thread, Emscripten and a<br>
> hypothetical new C backend or MSIL backend) are basically backends that<br>
> don't go through the SelectionDAG mechanism and largely bypass the current<br>
> backend logic that legalizes IR for a backend. The problem is that basically<br>
> all the targets in the LLVM tree use SelectionDAG and associated mechanisms.<br>
> Arguably the NVPTX backend might benefit from such an approach (since it<br>
> ultimately needs to allocate virtual registers), but I've never developed<br>
> any backends, so I don't know what the tradeoffs are there. In any case,<br>
> it's extremely unlikely that code which is only useful for IR-based backends<br>
> instead of SelectionDAG-based backends could be useful for any in-tree<br>
> targets.<br>
><br>
> In that frame of model, though, I do see a potential compromise: instead of<br>
> proposing virtual clones of what is essentially IR legalization for an<br>
> IR-based backend, why not attempt to generalize the current legalization<br>
> logic to work for IR-based backends instead of only SelectionDAG-based<br>
> backends?<br>
><br>
<br>
</div>I agree that is should be a lot easier to create a backend.<br>
See the below comment describing a virtual machine architecture.<br>
A complete CPU definition in 54 lines of text!!!<br>
For those interested, the 54 lines is taken from GCHQ.<br>
I think it would be useful to maybe use the below as an example<br>
backend template.<br>
<br>
I would also welcome more IR passes in the LLVM tree, even if the<br>
current backends don't use them.<br>
I can probably re-use them in my project.<br>
So long as there were tests for them, and an interested party could<br>
claim "MAINTAINER" for each one.<br>
A similar model to that of the Linux kernel MAINTAINER.<br>
Anyone can submit a device driver to the linux kernel and it will go<br>
into upstream mainline, so long as a "MAINTAINER" is identified.<br>
If the MAINTAINER becomes absent for a period of time, and no one else<br>
claims it, the driver is then removed again.<br>
A single LLVM IR pass is a relatively unobtrusive piece of the LLVM code base.<br>
How would adding a new LLVM IR pass into the upstream LLVM code base<br>
cause problems for the core MAINTAINERS?<br>
<br>
Kind Regards<br>
<br>
James<br>
<br>
<br>
<br>
exec: function()<br>
{<br>
// virtual machine architecture<br>
// ++++++++++++++++++++++++++++<br>
//<br>
// segmented memory model with 16-byte segment size (notation seg:offset)<br>
//<br>
// 4 general-purpose registers (r0-r3)<br>
// 2 segment registers (cs, ds equiv. to r4, r5)<br>
// 1 flags register (fl)<br>
//<br>
// instruction encoding<br>
// ++++++++++++++++++++<br>
//<br>
// byte 1 byte 2 (optional)<br>
// bits [ 7 6 5 4 3 2 1 0 ] [ 7 6 5 4 3 2 1 0 ]<br>
// opcode - - -<br>
// mod -<br>
// operand1 - - - -<br>
// operand2 - - - - - - - -<br>
//<br>
// operand1 is always a register index<br>
// operand2 is optional, depending upon the instruction set specified below<br>
// the value of mod alters the meaning of any operand2<br>
// 0: operand2 = reg ix<br>
// 1: operand2 = fixed immediate value or target segment<br>
(depending on instruction)<br>
//<br>
// instruction set<br>
// +++++++++++++++<br>
//<br>
// Notes:<br>
// * r1, r2 => operand 1 is register 1, operand 2 is register 2<br>
// * movr r1, r2 => move contents of register r2 into register r1<br>
//<br>
// opcode | instruction | operands (mod 0) | operands (mod 1)<br>
// -------+-------------+------------------+-----------------<br>
// 0x00 | jmp | r1 | r2:r1<br>
// 0x01 | movr | r1, r2 | rx, imm<br>
// 0x02 | movm | r1, [ds:r2] | [ds:r1], r2<br>
// 0x03 | add | r1, r2 | r1, imm<br>
// 0x04 | xor | r1, r2 | r1, imm<br>
// 0x05 | cmp | r1, r2 | r1, imm<br>
// 0x06 | jmpe | r1 | r2:r1<br>
// 0x07 | hlt | N/A | N/A<br>
//<br>
// flags<br>
// +++++<br>
//<br>
// cmp r1, r2 instruction results in:<br>
// r1 == r2 => fl = 0<br>
// r1 < r2 => fl = 0xff<br>
// r1 > r2 => fl = 1<br>
//<br>
// jmpe r1<br>
// => if (fl == 0) jmp r1<br>
// else nop<br>
<br>
throw "VM.exec not yet implemented";<br>
<div><div> }<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br></div></div>