[PATCH] D49691: [DAGCombine] Allow alias analysis with inline asm calls and GluedNodes.
Eli Friedman via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Dec 7 14:24:57 PST 2018
efriedma added a comment.
I'm not sure I like the algorithm here. It seems like it would be more straightforward to handle the INLINEASM and all the glued nodes together, in a separate inner loop.
================
Comment at: llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:18870
- case ISD::CopyFromReg:
+ case ISD::CopyFromReg: {
// Forward past CopyFromReg.
----------------
Wrong indentation.
================
Comment at: llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:18875
+ Chain->getOperand(0).getNode() == Chain->getOperand(LastOpNo).getNode();
+ // bool isGlued = Chain->getOperand(Chain->getNumOperands()-1).getValueType() == MVT::Glue;
+
----------------
Commented-out code?
================
Comment at: llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:18883
+ case ISD::CopyToReg: {
+ // Forward past CopyToRe
+ auto LastOpNo = Chain->getNumOperands()-1;
----------------
Incomplete comment?
================
Comment at: llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:18918
// For all other instructions we will just have to take what we can get.
- Aliases.push_back(Chain);
+ Visited.insert(Chain->getOperand(0).getNode());
+ Aliases.push_back(Alias);
----------------
I don't think there's an comment anywhere explaining why you're putting chain operands into the visited list? Thinking about it a bit, I guess you're trying to avoid computing "useless" aliases? Does that actually work reliably, given the visitation order of the operands of a TokenFactor is sort of arbitrary?
Repository:
rL LLVM
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D49691/new/
https://reviews.llvm.org/D49691
More information about the llvm-commits
mailing list