[all-commits] [llvm/llvm-project] d1f0bd: [SDAG] remove use restriction in isNegatibleForFre...

[RotateRight via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: d1f0bdf2d2df9bdf11ee2ddfff3df50e53f2f042
      https://github.com/llvm/llvm-project/commit/d1f0bdf2d2df9bdf11ee2ddfff3df50e53f2f042
  Author: Sanjay Patel <spatel at rotateright.com>
  Date:   2019-12-11 (Wed, 11 Dec 2019)

  Changed paths:
    M llvm/include/llvm/CodeGen/TargetLowering.h
    M llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp
    M llvm/lib/Target/X86/X86ISelLowering.cpp
    M llvm/lib/Target/X86/X86ISelLowering.h
    M llvm/test/CodeGen/AArch64/arm64-fmadd.ll
    M llvm/test/CodeGen/X86/fma-fneg-combine-2.ll

  Log Message:
  -----------
  [SDAG] remove use restriction in isNegatibleForFree() when called from getNegatedExpression()

This is an alternate fix for the bug discussed in D70595.
This also includes minimal tests for other in-tree targets
to show the problem more generally.

We check the number of uses as a predicate for whether some
value is free to negate, but that use count can change as we
rewrite the expression in getNegatedExpression(). So something
that was marked free to negate during the cost evaluation
phase becomes not free to negate during the rewrite phase (or
the inverse - something that was not free becomes free).
This can lead to a crash/assert because we expect that
everything in an expression that is negatible to be handled
in the corresponding code within getNegatedExpression().

This patch skips the use check during the rewrite phase.
So we determine that some expression isNegatibleForFree
(identically to without this patch), but during the rewrite,
don't rely on use counts to decide how to create the optimal
expression.

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