[PATCH] D31724: [SelectionDAG] Remove special call to LHS computeKnownBits for ANDs with constant RHS.

Craig Topper via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Apr 5 13:56:46 PDT 2017


craig.topper created this revision.
Herald added subscribers: tpr, nhaehnle, nemanjai, rengolin, aemerson.

This code seems largely unnecessary. Most of what it was currently fixing were differences between computeKnownBits and SimplifyDemandedBits for SETCC and AssertZExt. I've submitted a separate patch to clean that up.

This leaves us with the few test issues seen here.

The AArch64/fast-isel-select.ll test is because we now try to create -1 as the constant for the XOR when we descend through SimplifyDemandedBits for the LHS of the AND. Previously we descended down the LHS through computeKnownBits and then came back up and determined the AND was useless and deleted it. Now we go through SimplifyDemandedBits first and the XOR sees that the upper bits aren't demanded so it creates a -1. This gets folded into an ORN(or not) with the normal isel. The fast isel case doesn't go through SimplifyDemandedBits so doesn't get optimized. The AND instruction was always there in the fastisel case before this patch it just wasn't being checked for by FileCheck.

The PowerPC/rlwimi-and.ll test appears to be a case where there are multiple ANDs separated by other operations in a chain. Previously we removed a late AND in the chain because the earlier AND made it redundant. But now we remove the AND earlier in the chain because we see the later AND made it redundant.

The AMDGPU/fneg.f16.ll is similar to the PowerPC test in that there are multiple ANDs in a chain. In the original code we removed the late AND and kept an earlier AND. The earlier AND got folded with an anyext load to create a zext load. Now we remove the earlier AND and fail to create the ZEXT load because there is an XOR between the load and the AND. We could recover this if we had a DAG combine to move AND with a constant above an XOR with a constant if all the bits in the XOR constant are set in the AND constant.


https://reviews.llvm.org/D31724

Files:
  lib/CodeGen/SelectionDAG/TargetLowering.cpp
  test/CodeGen/AArch64/fast-isel-select.ll
  test/CodeGen/AMDGPU/fneg.f16.ll
  test/CodeGen/PowerPC/rlwimi-and.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D31724.94276.patch
Type: text/x-patch
Size: 5715 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170405/bb75318e/attachment-0001.bin>


More information about the llvm-commits mailing list