llvm dev - May 2017 - Some info about CALLSEQ_START/CALLSEQ_END

Hi,
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.

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).

Here's the before and after SDAG dump.
Before:
...
        t50: ch = CopyToReg t0, Register:i32 %vreg54, t48
        t60: ch,glue = callseq_end t59, TargetConstant:i64<32>,
TargetConstant:i64<0>, t59:1
      t68: ch = TokenFactor t50, t60
          t62: i32,ch = CopyFromReg t0, Register:i32 %vreg19
        t64: i1 = setcc t62, t48, setlt:ch
        t53: i1 = setcc t48, Constant:i32<-50000>, setne:ch
      t65: i1 = and t64, t53
    t74: ch = br_cc t68, setne:ch, t65, Constant:i1<-1>,
BasicBlock:ch<while.cond.outer 0x100137faf30>

After:
...
                  t77: i32 = EXTSW_32 t48
                    t62: i32,ch = CopyFromReg t0, Register:i32 %vreg19
                  t76: i32 = EXTSW_32 t62
                t78: i32 = SUBF t77, t76
              t81: i32 = RLDICL_32 t78, TargetConstant:i64<1>,
TargetConstant:i64<63>
            t91: i64 = INSERT_SUBREG IMPLICIT_DEF:i64, t81,
TargetConstant:i32<1>
                    t82: i32 = XOR t48, Constant:i32<-50000>
                  t83: i32 = CNTLZW t82
                t87: i32 = RLWINM t83, TargetConstant:i32<27>,
TargetConstant:i32<5>, TargetConstant:i32<31>
              t89: i32 = XORI t87, TargetConstant:i32<1>
            t92: i64 = INSERT_SUBREG IMPLICIT_DEF:i64, t89,
TargetConstant:i32<1>
          t94: i64,glue = AND8o t91, t92
        t96: i1 = EXTRACT_SUBREG Register:i32 %CR0, TargetConstant:i32<4>,
t94:1
      t75: i1 = CRXOR t96, Constant:i1<-1>
        t50: ch = CopyToReg t0, Register:i32 %vreg54, t48
        t60: ch,glue = callseq_end t59, TargetConstant:i64<32>,
TargetConstant:i64<0>, t59:1
      t68: ch = TokenFactor t50, t60
    t74: ch = BC t75, BasicBlock:ch<while.cond.outer 0x100137faf30>, t68
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170505/12d0e645/attachment.html>

On 5/5/2017 1:20 PM, Nemanja Ivanovic via llvm-dev
wrote:
> Hi,
> 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.
>
> 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).
>
> Here's the before and after SDAG dump.
> Before:
> ...
>         t50: ch = CopyToReg t0, Register:i32 %vreg54, t48
>         t60: ch,glue = callseq_end t59, TargetConstant:i64<32>, 
> TargetConstant:i64<0>, t59:1
>       t68: ch = TokenFactor t50, t60
>           t62: i32,ch = CopyFromReg t0, Register:i32 %vreg19
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.

-Eli

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170505/7d46fd2f/attachment.html>