[PATCH] D35267: Pass Divergence Analysis data to selection DAG to drive divergence dependent instruction selection
Stanislav Mekhanoshin via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Dec 12 01:18:52 PST 2017
rampitec added a comment.
In https://reviews.llvm.org/D35267#952151, @alex-t wrote:
> In https://reviews.llvm.org/D35267#949394, @alex-t wrote:
>
> > In https://reviews.llvm.org/D35267#948666, @rampitec wrote:
> >
> > > There actually can be problem with folding the node if we patch it after creation. At least this needs to be checked.
> >
> >
> > That's true. The problem is that in SelectionDAG::getNode (where the SCEMap insertion is) we have no Value and no chance to check it's divergence.
> > And this is correct: SelectionDAG is for selection and we should not expose the IR Values to it.
> >
> > The only way I see is to pass the Divergence parameter to getNode from all the SelectionDAGBuilder visitors. This will be correct but requires to change** each of 109 visitors** and getNode().
>
>
> In fact we have no chance to have 2 SDNodes that differ by the Divergence flag only.
> Please note that the selection operates per block. SelectionDAGBuilder construct the DAG for one block at a time.
> Then it selects and emits the code. Then all the data including CSE map get cleared.
> FoldingSetNodeID creates the hash including node and it's operands.
> Thus we hit the hash only if there is same node with same operands.
> Form the data dependency point it must have same divergence. So literally it is same node and setting same value of divergence flag makes no harm.
> The only case when we could have 2 nodes that differ by the divergence only is if both have same operands but one is control-dependent of the divergent branch.
> That immediately means that 2 nodes belong to different basic blocks and hence cannot be folded.
Thank you, that makes sense. I have no objections then, since creation of a node with a proper flags would result in a really massive patch changing all constructors and visitors. E.g. all node visitors would then need to gain a knowledge about a non node specific property. Post patching seems better to me.
https://reviews.llvm.org/D35267
More information about the llvm-commits
mailing list