[llvm-dev] Some info about CALLSEQ_START/CALLSEQ_END

[Friedman, Eli via llvm-dev]

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>