[all-commits] [llvm/llvm-project] 826f73: [InstCombine] Add test for PR46680 (NFC)

[Nikita Popov via All-commits]

  Branch: refs/heads/release/11.x
  Home:   https://github.com/llvm/llvm-project
  Commit: 826f730f3f1e2722059fe9d7f271a27a0d980a0f
      https://github.com/llvm/llvm-project/commit/826f730f3f1e2722059fe9d7f271a27a0d980a0f
  Author: Nikita Popov <nikita.ppv at gmail.com>
  Date:   2020-07-23 (Thu, 23 Jul 2020)

  Changed paths:
    A llvm/test/Transforms/InstCombine/pr46680.ll

  Log Message:
  -----------
  [InstCombine] Add test for PR46680 (NFC)

(cherry picked from commit 13ae440de4a408cf9d1a448def09769ecbecfdf7)


  Commit: eb3c5db40a1450d50c387f3a42f4c095001220cb
      https://github.com/llvm/llvm-project/commit/eb3c5db40a1450d50c387f3a42f4c095001220cb
  Author: Nikita Popov <nikita.ppv at gmail.com>
  Date:   2020-07-23 (Thu, 23 Jul 2020)

  Changed paths:
    M llvm/lib/Transforms/InstCombine/InstCombineInternal.h
    M llvm/test/Transforms/InstCombine/minmax-fold.ll
    M llvm/test/Transforms/InstCombine/pr46680.ll

  Log Message:
  -----------
  [InstCombine] Fix store merge worklist management (PR46680)

Fixes https://bugs.llvm.org/show_bug.cgi?id=46680.

Just like insertions through IRBuilder, InsertNewInstBefore()
should be using the deferred worklist mechanism, so that processing
of newly added instructions is prioritized.

There's one side-effect of the worklist order change which could be
classified as a regression. An add op gets pushed through a select
that at the time is not a umax. We could add a reverse transform
that tries to push adds in the reverse direction to restore a min/max,
but that seems like a sure way of getting infinite loops... Seems
like something that should best wait on min/max intrinsics.

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

(cherry picked from commit d12ec0f752e7f2c7f7252539da2d124264ec33f7)


Compare: https://github.com/llvm/llvm-project/compare/e9d37a2ee97f...eb3c5db40a14