[DAGCombiner] Add a command line option to guard ReduceLoadOpStoreWidth

[Carrot]

Summary

As discussed in the thread http://lists.llvm.org/pipermail/llvm-dev/2020-May/141838.html, some bit field access width can be reduced by ReduceLoadOpStoreWidth, some can't. If two accesses are very close, and the first access width is reduced, the second is not. Then the wide load of second access will be stalled for long time.

This patch guards the function ReduceLoadOpStoreWidth with a new command line option combiner-reduce-load-op-store-width, so it gives user a chance to disable ReduceLoadOpStoreWidth.

[efriedma]

llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp

15414

There are two separate transforms here: ShrinkLoadReplaceStoreWithStore, which actually erases the load, and the isNarrowingProfitable transform, which just shrinks the store. The performance implications might be different, so I think we want separate flags.

(We don't really want to encourage users to use these flags in production, but I think it's okay to add them to evaluate the performance impact.)

llvm/test/CodeGen/X86/clear-bitfield.ll

9

Probably we want to see what happens with i16 specifically, since there's some weirdness involving the encodings.

Please generate checks with update_llc_test_checks.py.

[void]

llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp

15414

Would using this flag in isNarrowingProfitable (or conditionalizing the execution of same with the flag) better?

(We don't really want to encourage users to use these flags in production, but I think it's okay to add them to evaluate the performance impact.)

Agreed. I think it's better to have a better heuristic to determine if narrowing is profitable.

[Carrot]

llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp

15414

isNarrowingProfitable is also used to reduce load and other alu width, these don't stall following load.

I added a new flag to guard ShrinkLoadReplaceStoreWithStore.

[efriedma]

LGTM

llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp

static cl::opt<unsigned> TokenFactorInlineLimit(
     "combiner-tokenfactor-inline-limit", cl::Hidden, cl::init(2048),
     cl::desc("Limit the number of operands to inline for Token Factors"));
 
 static cl::opt<unsigned> StoreMergeDependenceLimit(
     "combiner-store-merge-dependence-limit", cl::Hidden, cl::init(10),
     cl::desc("Limit the number of times for the same StoreNode and RootNode "
              "to bail out in store merging dependence check"));
 
+static cl::opt<bool> EnableReduceLoadOpStoreWidth(
+    "combiner-reduce-load-op-store-width", cl::Hidden, cl::init(true),
+    cl::desc("DAG cominber enable reducing the width of load/op/store "
+             "sequence"));
+
 namespace {
 
   class DAGCombiner {
     SelectionDAG &DAG;
     const TargetLowering &TLI;
     CombineLevel Level;
     CodeGenOpt::Level OptLevel;
     bool LegalDAG = false;
return DAG
                 St->getPointerInfo().getWithOffset(StOffset), NewAlign);
 }
 
 /// Look for sequence of load / op / store where op is one of 'or', 'xor', and
 /// 'and' of immediates. If 'op' is only touching some of the loaded bits, try
 /// narrowing the load and store if it would end up being a win for performance
 /// or code size.
 SDValue DAGCombiner::ReduceLoadOpStoreWidth(SDNode *N) {
+  if (!EnableReduceLoadOpStoreWidth)
+    return SDValue();
+
   StoreSDNode *ST  = cast<StoreSDNode>(N);
   if (!ST->isSimple())
     return SDValue();
 
   SDValue Chain = ST->getChain();
   SDValue Value = ST->getValue();
   SDValue Ptr   = ST->getBasePtr();
   EVT VT = Value.getValueType();

llvm/test/CodeGen/X86/clear-bitfield.ll

+; RUN: llc < %s -mtriple=x86_64-- -combiner-reduce-load-op-store-width=false | FileCheck %s
+
+%struct.bit_fields = type { i32 }
+
+; CHECK:  andl $-2, (%rdi)
+define void @clear_b1(%struct.bit_fields* %ptr) {
+entry:
+  %0 = bitcast %struct.bit_fields* %ptr to i32*
+  %bf.load = load i32, i32* %0
+  %bf.clear = and i32 %bf.load, -2
+  store i32 %bf.clear, i32* %0
+  ret void
+}
+