summaryrefslogtreecommitdiffstats
path: root/llvm/lib
diff options
context:
space:
mode:
authorSanjay Patel <spatel@rotateright.com>2018-12-08 16:07:38 +0000
committerSanjay Patel <spatel@rotateright.com>2018-12-08 16:07:38 +0000
commite767bf446840e65c5e84fbc89454c3d7d04b771d (patch)
tree2b0ddb4879092263ace9ed78143a42e239ac9928 /llvm/lib
parent04461ee821d7713c870e4749f3a235c642ef60f8 (diff)
downloadbcm5719-llvm-e767bf446840e65c5e84fbc89454c3d7d04b771d.tar.gz
bcm5719-llvm-e767bf446840e65c5e84fbc89454c3d7d04b771d.zip
[DAGCombiner] re-enable truncation of binops
This is effectively re-committing the changes from: rL347917 (D54640) rL348195 (D55126) ...which were effectively reverted here: rL348604 ...because the code had a bug that could induce infinite looping or eventual out-of-memory compilation. The bug was that this code did not guard against transforming opaque constants. More details are in the post-commit mailing list thread for r347917. A reduced test for that is included in the x86 bool-math.ll file. (I wasn't able to reduce a PPC backend test for this, but it was almost the same pattern.) Original commit message for r347917: The motivating case for this is shown in: https://bugs.llvm.org/show_bug.cgi?id=32023 and the corresponding rot16.ll regression tests. Because x86 scalar shift amounts are i8 values, we can end up with trunc-binop-trunc sequences that don't get folded in IR. As the TODO comments suggest, there will be regressions if we extend this (for x86, we mostly seem to be missing LEA opportunities, but there are likely vector folds missing too). I think those should be considered existing bugs because this is the same transform that we do as an IR canonicalization in instcombine. We just need more tests to make those visible independent of this patch. llvm-svn: 348706
Diffstat (limited to 'llvm/lib')
-rw-r--r--llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp19
1 files changed, 7 insertions, 12 deletions
diff --git a/llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp b/llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
index bf476867a8d..24531c3cc85 100644
--- a/llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
+++ b/llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
@@ -112,12 +112,6 @@ static cl::opt<bool>
MaySplitLoadIndex("combiner-split-load-index", cl::Hidden, cl::init(true),
cl::desc("DAG combiner may split indexing from loads"));
-// This is a temporary debug flag to disable a combine that is known to
-// conflict with another combine.
-static cl::opt<bool>
-NarrowTruncatedBinops("narrow-truncated-binops", cl::Hidden, cl::init(false),
- cl::desc("Move truncates ahead of binops"));
-
namespace {
class DAGCombiner {
@@ -9814,9 +9808,10 @@ SDValue DAGCombiner::visitTRUNCATE(SDNode *N) {
if (SDValue NewVSel = matchVSelectOpSizesWithSetCC(N))
return NewVSel;
- // Narrow a suitable binary operation with a constant operand by moving it
- // ahead of the truncate. This is limited to pre-legalization because targets
- // may prefer a wider type during later combines and invert this transform.
+ // Narrow a suitable binary operation with a non-opaque constant operand by
+ // moving it ahead of the truncate. This is limited to pre-legalization
+ // because targets may prefer a wider type during later combines and invert
+ // this transform.
switch (N0.getOpcode()) {
// TODO: Add case for ADD - that will likely require a change in logic here
// or target-specific changes to avoid regressions.
@@ -9825,9 +9820,9 @@ SDValue DAGCombiner::visitTRUNCATE(SDNode *N) {
case ISD::AND:
case ISD::OR:
case ISD::XOR:
- if (NarrowTruncatedBinops && !LegalOperations && N0.hasOneUse() &&
- (isConstantOrConstantVector(N0.getOperand(0)) ||
- isConstantOrConstantVector(N0.getOperand(1)))) {
+ if (!LegalOperations && N0.hasOneUse() &&
+ (isConstantOrConstantVector(N0.getOperand(0), true) ||
+ isConstantOrConstantVector(N0.getOperand(1), true))) {
// TODO: We already restricted this to pre-legalization, but for vectors
// we are extra cautious to not create an unsupported operation.
// Target-specific changes are likely needed to avoid regressions here.
OpenPOWER on IntegriCloud