[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