[llvm-dev] Doubts

[Ahmed Bougacha via llvm-dev]

On Tue, Jun 7, 2016 at 1:56 PM, Pedro Lopes <pedro.fraiao at gmail.com> wrote:
> Hello Ahmed,
>
> Thanks for your explanation. While very clarifying, your response created a
> lot of questions in my mind.
>
> I could not understand what you meant by:
>
> "It's the operator used to "set" registers (the first operands) to
> given values (the last operand, usually a DAG)."
>
> Should I be thinking in terms of basic blocks where multiple operands create
> a SelectionDAG and produce a result for example? Or maybe think about the
> union of SDNodes to form MachineInstr by pattern matching?

Oh, no, sorry: here, "DAG" refers to the TableGen "dag" construct, the
stuff you write in parentheses.  The "operator" is the first part of a
dag.

What I mean by "usually a DAG" is that it's obviously more common to
have a dag child:
  (set GR32:$dst, (add ...))
instead of a leaf child like:
  (set GR32:$dst, 123)
or:
  (set GR32:$dst, GR32:$src)

> When you presented the following pattern: "[(set GR32:$dst, EFLAGS,
> (X86add_flag GR32:$src1, GR32:$src2))]" you made me realize that maybe I
> don't fully understand pattern matching. I know that pattern matching uses
> the SelectionDAG with SDNodes and produces a SelectionDAG of MachineInstr,
> but when you use registers as operands in a pattern what does it mean? I
> believe the first DAG, before instruction selection, is kind of register
> agnostic exept for the RegisterSDNode. By that logic, you only could VTs and
> not Registers, although they are widely used.

Yes, we're not matching registers, only VTs.  But the pattern is used
for more than matching, it's also used for transforming one
representation (SDNodes) into another (MachineInstr) via an
intermediate (MachineSDNode).

"GR32" is actually redundant in that example.  The interesting part is
the name of each operand ("$dst"), which is what determines the order
of the MachineOperands on the final MachineInstr (it also determines
the order of the results/operands (for ops in "outs" and "ins") of the
MachineSDNode).

In theory, I think even the types are unnecessary, and you should be
able to write patterns with just operand names ("(set $dst, ...)"),
but that's not currently accepted by tablegen.

> Regarding pattern's syntax, you can have various outputs, which number
> depend on the last operand being matched, but only one operand, I'm I
> correct?

Correct.

> Thanks a lot for the detailed explanation.
>
> (Also, if you could redirect me to more information about block
> live-ins/-outs I would be most grateful.)

Eh, unfortunately, none of this is very well documented; you might
have some luck with the comments and code in SelectionDAGBuilder,
FunctionLoweringInfo, and MachineBasicBlock.

-Ahmed