[all-commits] [llvm/llvm-project] d12ec0: [InstCombine] Fix store merge worklist management ...

[Nikita Popov via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: d12ec0f752e7f2c7f7252539da2d124264ec33f7
      https://github.com/llvm/llvm-project/commit/d12ec0f752e7f2c7f7252539da2d124264ec33f7
  Author: Nikita Popov <nikita.ppv at gmail.com>
  Date:   2020-07-19 (Sun, 19 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