[all-commits] [llvm/llvm-project] bdaa3f: Revert "[InstCombine] Take 2: Perform trivial PHI ...

Roman Lebedev via All-commits all-commits at lists.llvm.org
Sat Aug 29 06:05:45 PDT 2020


  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: bdaa3f86a040b138c58de41d73d35b76fdec1380
      https://github.com/llvm/llvm-project/commit/bdaa3f86a040b138c58de41d73d35b76fdec1380
  Author: Roman Lebedev <lebedev.ri at gmail.com>
  Date:   2020-08-29 (Sat, 29 Aug 2020)

  Changed paths:
    M llvm/lib/Transforms/InstCombine/InstCombinePHI.cpp
    M llvm/test/Transforms/InstCombine/merging-multiple-stores-into-successor.ll
    M llvm/test/Transforms/InstCombine/phi-aware-aggregate-reconstruction.ll
    M llvm/test/Transforms/InstCombine/phi-cse.ll
    M llvm/test/Transforms/InstCombine/phi-equal-incoming-pointers.ll
    M llvm/test/Transforms/InstCombine/select.ll
    M llvm/test/Transforms/LoopVectorize/reduction.ll

  Log Message:
  -----------
  Revert "[InstCombine] Take 2: Perform trivial PHI CSE"

While the original variant with doing this in InstSimplify (rightfully)
caused questions and ultimately was detected to be a culprit
of stage2-stage3 mismatch, it was expected that
InstCombine-based implementation would be fine.

But apparently it's not, as
http://lab.llvm.org:8011/builders/clang-with-thin-lto-ubuntu/builds/24095/steps/compare-compilers/logs/stdio
suggests.

Which suggests that somewhere in InstCombine there is a loop
over nondeterministically sorted container, which causes
different worklist ordering.

This reverts commit 3e69871ab5a66fb55913a2a2f5e7f5b42899a4c9.




More information about the All-commits mailing list