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

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