If we're trying to match an LEA, its possible the LEA match will be deemed unprofitable. In which case the negation we created in matchAddress would be left dangling in the SelectionDAG. This could artificially increase use counts for other nodes in the DAG. Though I don't have an example of that. But it just seems like bad form to have dangling nodes in isel.
Details
- Reviewers
niravd RKSimon spatel - Commits
- rZORG53ca53d6faa5: [X86] Delay creating index register negations during address matching until…
rG53ca53d6faa5: [X86] Delay creating index register negations during address matching until…
rGe43bdf144c9a: [X86] Delay creating index register negations during address matching until…
rL360823: [X86] Delay creating index register negations during address matching until…
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 31834 Build 31833: arc lint + arc unit
Event Timeline
llvm/lib/Target/X86/X86ISelDAGToDAG.cpp | ||
---|---|---|
267 | Can we deal with negation here rather than duplicating code in the callers? |
llvm/lib/Target/X86/X86ISelDAGToDAG.cpp | ||
---|---|---|
267 | We're missing the address root we would need for the insertDAGNode calls, but I can add it. |
-Move into getAddressOperands.
-Emit the NEG machine directly as I'm not sure I trust accessing N at this point in the code to use insertDAGNode. N can be changed by CSEing and other DAG modifications that can occur during address matching.
-Add -pre-RA-sched=linearize to one test that would fail previously due to the dangling sub node getting left behind when LEA costing failed.
LGTM
llvm/test/CodeGen/X86/imul.ll | ||
---|---|---|
6 | Is it worth doing FileCheck on this run too? Either it's the same as the others or different in some way that is interesting? |
Can we deal with negation here rather than duplicating code in the callers?