[all-commits] [llvm/llvm-project] 3180af: [InstCombine] reassociate fsub+fsub into fsub+fadd

[RotateRight via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 3180af4362be22d416464f5f3700c456b2f124b9
      https://github.com/llvm/llvm-project/commit/3180af4362be22d416464f5f3700c456b2f124b9
  Author: Sanjay Patel <spatel at rotateright.com>
  Date:   2020-01-15 (Wed, 15 Jan 2020)

  Changed paths:
    M llvm/lib/Transforms/InstCombine/InstCombineAddSub.cpp
    M llvm/test/Transforms/InstCombine/fsub.ll
    M llvm/test/Transforms/Reassociate/fast-SubReassociate.ll
    M llvm/test/Transforms/Reassociate/fast-basictest.ll

  Log Message:
  -----------
  [InstCombine] reassociate fsub+fsub into fsub+fadd

As discussed in the motivating PR44509:
https://bugs.llvm.org/show_bug.cgi?id=44509

...we can end up with worse code using fast-math than without.
This is because the reassociate pass greedily transforms fsub
into fneg/fadd and apparently (based on the regression tests
seen here) expects instcombine to clean that up if it wasn't
profitable. But we were missing this fold:

(X - Y) - Z --> X - (Y + Z)

There's another, more specific case that I think we should
handle as shown in the "fake" fneg test (but missed with a real
fneg), but that's another patch. That may be tricky to get
right without conflicting with existing transforms for fneg.

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