[all-commits] [llvm/llvm-project] daee54: [FPEnv][SelectionDAG] Relax chain requirements

[Ulrich Weigand via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: daee549b1756a7aa0f1560d5460ae580897e4c1a
      https://github.com/llvm/llvm-project/commit/daee549b1756a7aa0f1560d5460ae580897e4c1a
  Author: Ulrich Weigand <ulrich.weigand at de.ibm.com>
  Date:   2019-12-06 (Fri, 06 Dec 2019)

  Changed paths:
    M llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
    M llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp
    M llvm/lib/Target/SystemZ/SystemZInstrFP.td
    M llvm/test/CodeGen/SystemZ/fp-strict-mul-02.ll
    M llvm/test/CodeGen/SystemZ/fp-strict-mul-04.ll
    M llvm/test/CodeGen/SystemZ/vector-constrained-fp-intrinsics.ll
    M llvm/test/CodeGen/X86/fp-intrinsics.ll
    M llvm/test/CodeGen/X86/fp128-cast-strict.ll
    M llvm/test/CodeGen/X86/fp128-libcalls-strict.ll
    M llvm/test/CodeGen/X86/vector-constrained-fp-intrinsics.ll

  Log Message:
  -----------
  [FPEnv][SelectionDAG] Relax chain requirements

This patch implements the following changes:

1) SelectionDAGBuilder::visitConstrainedFPIntrinsic currently treats
each constrained intrinsic like a global barrier (e.g. a function call)
and fully serializes all pending chains. This is actually not required;
it is allowed for constrained intrinsics to be reordered w.r.t one
another or (nonvolatile) memory accesses. The MI-level scheduler already
allows for that flexibility, so it makes sense to allow it at the DAG
level as well.

This patch therefore changes the way chains for constrained intrisincs
are created, and handles them basically like load operations are handled.
This has the effect that constrained intrinsics are no longer serialized
against one another or (nonvolatile) loads. They are still serialized
against stores, but that seems hard to change with the current DAG chain
setup, and it also doesn't seem to be a big problem preventing DAG

2) The OPC_CheckFoldableChainNode check requires that each of the
intermediate nodes in a multi-node pattern match only has a single use.
This check tends to fail if those intermediate nodes are strict operations
as those have a chain output that typically indeed has another use.
However, we don't really need to consider chains here at all, since they
will all be rewritten anyway by UpdateChains later. Other parts of the
matcher therefore already ignore chains, but this hasOneUse check doesn't.

This patch replaces hasOneUse by a custom test that verifies there is no
more than one use of any non-chain output value.

In theory, this change could affect code unrelated to strict FP nodes,
but at least on SystemZ I could not find any single instance of that
happening

3) The SystemZ back-end currently does not allow matching multiply-and-
extend operations (32x32 -> 64bit or 64x64 -> 128bit FP multiply) for
strict FP operations.  This was not possible in the past due to the
problems described under 1) and 2) above.

With those issues fixed, it is now possible to fully support those
instructions in strict mode as well, and this patch does so.

Differential Revision: https://reviews.llvm.org/D70913