[LLVMdev] selecting ISD node - help

Tim Northover t.p.northover at gmail.com
Sat Feb 8 06:34:56 PST 2014


Hi DaAn,

> From what I understood this needs a Token Factor node, nodes which are
> dependent on each other?

A TokenFactor probably isn't needed here. That's for when you have a
bunch of operations and you want to say to LLVM that you don't care
what order they happen in amongst themselves but certain things have
to happen after all of them have completed.

In this case, the most obvious analogue is probably division on x86,
which also has fixed registers (no doubt other instructions do too,
but that's the one I know about). If you compile a simple division
function:

define i32 @foo(i32 %a, i32 %b) {
  %res = sdiv i32 %a, %b
  ret i32 %res
}

with: llc simple.ll -view-sched-dags you should get a nice post-script
rendered view of what's going on.

You seem to have the most important bit already: the instruction
should be bracketed by copyToReg and copyFromReg nodes. I think the
bit that might be missing is that all three nodes should be connected
by what's called "glue" (drawn in red on that view-sched-dags output).

A "chain" (the dotted blue lines your code is attempting to use)
probably isn't enough because LLVM might feel free to put unrelated
instructions in the middle, which could clobber your registers --
there's no data-dependence as far as LLVM is concerned at this stage.

The code used for DIV is around X86ISelDAGToDAG.cpp:2415, but from a
glance the key points seem to be:
1. use the second result of getCopyToReg (i.e. SDValue(setIdNode, 1))
in the RDMSR node.
2. Give your RDMSR node type MVT::Glue instead of MVT::Other

You should then return the first output of the CopyFromReg node itself.

That said, none of this addresses your actual error message.
Fortunately, it looks like it's happening a bit later so I'd only
worry about it if it still occurred when the DAG was looking how I
expected (via -view-sched-dags).

Hope this helps. Let me know if you have more problems.

Tim.



More information about the llvm-dev mailing list