diff options
| author | Hal Finkel <hfinkel@anl.gov> | 2015-09-06 05:42:13 +0000 |
|---|---|---|
| committer | Hal Finkel <hfinkel@anl.gov> | 2015-09-06 05:42:13 +0000 |
| commit | 10aac5fd0e5c2649571862aeb1e78228dcba3098 (patch) | |
| tree | 493b753972ddd8ec9c737b9d61789efc79ff911e /llvm/lib/Transforms | |
| parent | ccf9259c00ad60457c07b658a4167204ee53da12 (diff) | |
| download | bcm5719-llvm-10aac5fd0e5c2649571862aeb1e78228dcba3098.tar.gz bcm5719-llvm-10aac5fd0e5c2649571862aeb1e78228dcba3098.zip | |
[SelectionDAG] Swap commutative binops before constant-based folding
In searching for a fix for the underlying code-quality bug highlighted by
r246937 (that SDAG simplification can lead to us generating an ISD::OR node
with a constant zero LHS), I ran across this:
We generically canonicalize commutative binary-operation nodes in SDAG getNode
so that, if only one operand is a constant, it will be on the RHS. However, we
were doing this only after a bunch of constant-based simplification checks that
all assume this canonical form (that any constant will be on the RHS). Moving
the operand-swapping canonicalization prior to these checks seems like the
right thing to do (and, as it turns out, causes SDAG to completely fold away the
computation in test/CodeGen/ARM/2012-11-14-subs_carry.ll, just like InstCombine
would do).
llvm-svn: 246938
Diffstat (limited to 'llvm/lib/Transforms')
0 files changed, 0 insertions, 0 deletions
