en Copyright 2015 Java http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Transforms/IndVarSimplify/exit-count-select.ll#e9a1c82d [SCEVExpander] Expand umin_seq using freeze%x umin_seq %y is currently expanded to %x == 0 ? 0 : umin(%x, %y).This patch changes the expansion to umin(%x, freeze %y) instead(https://alive2.llvm.org/ce/z/wujUhp).The motivation for this change are the test cases affected byD124910, where the freeze expansion ultimately produces betteroptimization results. This is largely because`(%x umin_seq %y) == %x` is a common expansion pattern, whichreliably optimizes in freeze representation, but only sometimeswith the zero comparison (in particular, if %x == 0 can fold tosomething else, we generally won't be able to cover reasonablecode from this.)Differential Revision: https://reviews.llvm.org/D125372 List of files: /llvm-project-15.0.7/llvm/test/Transforms/IndVarSimplify/exit-count-select.ll Wed, 11 May 2022 10:34:16 +0000 Nikita Popov <npopov@redhat.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Transforms/IndVarSimplify/exit-count-select.ll#76a0abbc [SCEV] Reenable umin_seq support and fix the `computeSCEVAtScope()`This reverts commit f62f47f5e1f641b41d3b7d593c058ebec2883534. List of files: /llvm-project-15.0.7/llvm/test/Transforms/IndVarSimplify/exit-count-select.ll Tue, 11 Jan 2022 12:51:43 +0000 Roman Lebedev <lebedev.ri@gmail.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Transforms/IndVarSimplify/exit-count-select.ll#f62f47f5 Partial revert of 82fb4f4Two crashes have been reported. This change disables the new logic while leaving the new node in tree. Hopefully, that's enough to allow investigation without breakage while avoiding massive churn. List of files: /llvm-project-15.0.7/llvm/test/Transforms/IndVarSimplify/exit-count-select.ll Tue, 11 Jan 2022 02:17:34 +0000 Philip Reames <listmail@philipreames.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Transforms/IndVarSimplify/exit-count-select.ll#82fb4f4b [SCEV] Sequential/in-order `UMin` expressionAs discussed in https://github.com/llvm/llvm-project/issues/53020 / https://reviews.llvm.org/D116692,SCEV is forbidden from reasoning about 'backedge taken count'if the branch condition is a poison-safe logical operation,which is conservatively correct, but is severely limiting.Instead, we should have a way to express thosepoison blocking properties in SCEV expressions.The proposed semantics is:```Sequential/in-order min/max SCEV expressions are non-commutative variantsof commutative min/max SCEV expressions. If none of their operandsare poison, then they are functionally equivalent, otherwise,if the operand that represents the saturation point* of given expression,comes before the first poison operand, then the whole expression is not poison,but is said saturation point.```* saturation point - the maximal/minimal possible integer value for the given typeThe lowering is straight-forward:```compare each operand to the saturation point,perform sequential in-order logical-or (poison-safe!) ordered reductionover those checks, and if reduction returned true then returnsaturation point else return the naive min/max reduction over the operands```https://alive2.llvm.org/ce/z/Q7jxvH (2 ops)https://alive2.llvm.org/ce/z/QCRrhk (3 ops)Note that we don't need to check the last operand: https://alive2.llvm.org/ce/z/abvHQSNote that this is not commutative: https://alive2.llvm.org/ce/z/FK9e97That allows us to handle the patterns in question.Reviewed By: nikic, reamesDifferential Revision: https://reviews.llvm.org/D116766 List of files: /llvm-project-15.0.7/llvm/test/Transforms/IndVarSimplify/exit-count-select.ll Mon, 10 Jan 2022 17:49:41 +0000 Roman Lebedev <lebedev.ri@gmail.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Transforms/IndVarSimplify/exit-count-select.ll#6a563e25 [NFC][SCEV][IndVars] Add more tests for exit count w/ `select`See https://github.com/llvm/llvm-project/issues/53020 List of files: /llvm-project-15.0.7/llvm/test/Transforms/IndVarSimplify/exit-count-select.ll Thu, 06 Jan 2022 22:25:53 +0000 Roman Lebedev <lebedev.ri@gmail.com>