<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 5/5/2017 1:20 PM, Nemanja Ivanovic
      via llvm-dev wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAObEeNjb2ULu5011f8=yVZUFgfNC7Ct49S8Sv1+wquTKcJFH7Q@mail.gmail.com">
      <div dir="ltr">
        <div>
          <div>
            <div>
              <div>
                <div>Hi,<br>
                </div>
                I have an SelDAG visitor function that will transform an
                ISD::AND (if its inputs are both ISD::SETCC) into a
                bunch of target specific code. The transformation passes
                double bootstrap with full lit/lnt testing but I have
                one failure in a small benchmark that I have narrowed
                down to one instance of the transformation (selection).
                And it looks somewhat strange for me.<br>
                <br>
              </div>
              Namely, one of the ISD::SETCC nodes has an input that is a
              CopyFromReg that appears after the `callseq_end` node.
              After I select this to the target specific code, that
              CopyFromReg (along with all the target specific code)
              moves up past the `callseq_end` node (so that it's within
              the callseq_begin/callseq_end pair). Now I don't know
              whether these nodes are supposed to be some kind of
              barriers thereby making this hoisting illegal. I'd
              appreciate some guidance on this (even if it is to just
              say this is perfectly legal and is not the source of my
              bug).<br>
              <br>
            </div>
            Here's the before and after SDAG dump.<br>
          </div>
          Before:<br>
          <span style="font-family:monospace,monospace">...<br>
                    t50: ch = CopyToReg t0, Register:i32 %vreg54, t48<br>
                    t60: ch,glue = callseq_end t59,
            TargetConstant:i64<32>, TargetConstant:i64<0>,
            t59:1<br>
                  t68: ch = TokenFactor t50, t60<br>
                      t62: i32,ch = CopyFromReg t0, Register:i32 %vreg19<br>
          </span></div>
      </div>
    </blockquote>
    <br>
    t62 isn't "after" the callseq_end; the SelectionDAG is, as the name
    states, a DAG.  The order of nodes in the dump isn't significant. 
    The CopyFromReg is chained to the entry block, and nothing uses the
    chain of the CopyFromReg, so it can be scheduled anywhere in the
    block.<br>
    <br>
    -Eli<br>
    <pre class="moz-signature" cols="72">-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project</pre>
  </body>
</html>