On 64-bit target, when doing i64 BR_CC where one of the comparison operands is a constant zero, try to fold the compare and BPcc into a BPr instruction. For all integers, EQ and NE comparison are available, additionally for signed integers, GT, GE, LT, and LE is also available. Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D142461
This reverts commit 6590a372fa3f4582c04b4b179f90a3c728e75025.
On 64-bit target, when doing i64 BR_CC where one of the comparison operands is a constant zero, try to fold the compare and BPcc into a BPr instruction. For all integers, EQ and NE comparison are available, additionally for signed integers, GT, GE, LT, and LE is also available. Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D142461
Materialize zeros by copying from %g0, which is now marked as constant. This makes it possible for some common operations (like integer negation) to be performed in fewer instructions. This continues @arichardson's patch at D132561. Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D138887
2 of the Sparc tests are now failing. This reverts commit 2c41310fc146a1f609147c65ac5f30e5a57e84a8.
Materialize zeros by copying from %g0, which is now marked as constant. This makes it possible for some common operations (like integer negation) to be performed in fewer instructions. This continues @arichardson's patch at D132561. Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D138887
Do not emit deprecated v8-style branches when targeting a v9 processor. As a side effect, this also fixes the emission of useless ba's when doing conditional branches on 64-bit integer values. Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D130006
Current approach doesn't work well in cases when multiple paths are predicted to be "cold". By "cold" paths I mean those containing "unreachable" instruction, call marked with 'cold' attribute and 'unwind' handler of 'invoke' instruction. The issue is that heuristics are applied one by one until the first match and essentially ignores relative hotness/coldness of other paths. New approach unifies processing of "cold" paths by assigning predefined absolute weight to each block estimated to be "cold". Then we propagate these weights up/down IR similarly to existing approach. And finally set up edge probabilities based on estimated block weights. One important difference is how we propagate weight up. Existing approach propagates the same weight to all blocks that are post-dominated by a block with some "known" weight. This is useless at least because it always gives 50\50 distribution which is assumed by default anyway. Worse, it causes the algorithm to skip further heuristics and can miss setting more accurate probability. New algorithm propagates the weight up only to the blocks that dominates and post-dominated by a block with some "known" weight. In other words, those blocks that are either always executed or not executed together. In addition new approach processes loops in an uniform way as well. Essentially loop exit edges are estimated as "cold" paths relative to back edges and should be considered uniformly with other coldness/hotness markers. Reviewed By: yrouban Differential Revision: https://reviews.llvm.org/D79485
First half of PR40800, this patch adds DAG undef handling to icmp instructions to match the behaviour in llvm::ConstantFoldCompareInstruction and SimplifyICmpInst, this permits constant folding of vector comparisons where some elements had been reduced to UNDEF (by SimplifyDemandedVectorElts etc.). This involved a lot of tweaking to reduced tests as bugpoint loves to reduce icmp arguments to undef........ Differential Revision: https://reviews.llvm.org/D59363 llvm-svn: 356938
llvm-svn: 356253