[LLVMdev] Upstreaming PNaCl's IR simplification passes

[James Courtier-Dutton]

>
> 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?
>

I agree that is should be a lot easier to create a backend.
See the below comment describing a virtual machine architecture.
A complete CPU definition in 54 lines of text!!!
For those interested, the 54 lines is taken from GCHQ.
I think it would be useful to maybe use the below as an example
backend template.

I would also welcome more IR passes in the LLVM tree, even if the
current backends don't use them.
I can probably re-use them in my project.
So long as there were tests for them, and an interested party could
claim "MAINTAINER" for each one.
A similar model to that of the Linux kernel MAINTAINER.
Anyone can submit a device driver to the linux kernel and it will go
into upstream mainline, so long as a "MAINTAINER" is identified.
If the MAINTAINER becomes absent for a period of time, and no one else
claims it, the driver is then removed again.
A single LLVM IR pass is a relatively unobtrusive piece of the LLVM code base.
How would adding a new LLVM IR pass into the upstream LLVM code base
cause problems for the core MAINTAINERS?

Kind Regards

James



 exec: function()
  {
    // virtual machine architecture
    // ++++++++++++++++++++++++++++
    //
    // segmented memory model with 16-byte segment size (notation seg:offset)
    //
    // 4 general-purpose registers (r0-r3)
    // 2 segment registers (cs, ds equiv. to r4, r5)
    // 1 flags register (fl)
    //
    // instruction encoding
    // ++++++++++++++++++++
    //
    //           byte 1               byte 2 (optional)
    // bits      [ 7 6 5 4 3 2 1 0 ]  [ 7 6 5 4 3 2 1 0 ]
    // opcode      - - -
    // mod               -
    // operand1            - - - -
    // operand2                         - - - - - - - -
    //
    // operand1 is always a register index
    // operand2 is optional, depending upon the instruction set specified below
    // the value of mod alters the meaning of any operand2
    //   0: operand2 = reg ix
    //   1: operand2 = fixed immediate value or target segment
(depending on instruction)
    //
    // instruction set
    // +++++++++++++++
    //
    // Notes:
    //   * r1, r2 => operand 1 is register 1, operand 2 is register 2
    //   * movr r1, r2 => move contents of register r2 into register r1
    //
    // opcode | instruction | operands (mod 0) | operands (mod 1)
    // -------+-------------+------------------+-----------------
    // 0x00   | jmp         | r1               | r2:r1
    // 0x01   | movr        | r1, r2           | rx,   imm
    // 0x02   | movm        | r1, [ds:r2]      | [ds:r1], r2
    // 0x03   | add         | r1, r2           | r1,   imm
    // 0x04   | xor         | r1, r2           | r1,   imm
    // 0x05   | cmp         | r1, r2           | r1,   imm
    // 0x06   | jmpe        | r1               | r2:r1
    // 0x07   | hlt         | N/A              | N/A
    //
    // flags
    // +++++
    //
    // cmp r1, r2 instruction results in:
    //   r1 == r2 => fl = 0
    //   r1 < r2  => fl = 0xff
    //   r1 > r2  => fl = 1
    //
    // jmpe r1
    //   => if (fl == 0) jmp r1
    //      else nop

    throw "VM.exec not yet implemented";
  }