summaryrefslogtreecommitdiff
path: root/lib/Transforms/Utils/SimplifyCFG.cpp
Commit message (Collapse)AuthorAge
* Transforms: Don't create bad weights when eliminating dead casesJustin Bogner2013-12-20
| | | | | | | | | If we happen to eliminate every case in a switch that has branch weights, we currently try to create metadata for the one remaining branch, triggering an assert. Instead, we need to check that the metadata we're trying to create is sensible. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197791 91177308-0d34-0410-b5e6-96231b3b80d8
* FoldBranchToCommonDest merges branches into a single branch with or/and of ↵Nadav Rotem2013-11-12
| | | | | | the condition. It has a heuristics for estimating when some of the dependencies are processed by out-of-order processors. This patch adds another rule to the heuristics that says that if the "BonusInstruction" that we speculatively execute is used by the condition of the second branch then it is okay to hoist it. This change exposes more opportunities for other passes to transform the code. It does not matter that much that we if-convert the code because the selectiondag builder splits or/and branches into multiple branches when profitable. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194524 91177308-0d34-0410-b5e6-96231b3b80d8
* SimplifyCFG: Use existing constant folding logic when forming switch tables.Benjamin Kramer2013-11-12
| | | | | | Both simpler and more powerful than the hand-rolled folding logic. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194475 91177308-0d34-0410-b5e6-96231b3b80d8
* SimplifyCFG has a heuristics for out-of-order processors that decides when ↵Nadav Rotem2013-11-10
| | | | | | | | | it is worthwhile to merge branches. It tries to estimate if the operands of the instruction that we want to hoist are ready. This commit marks function arguments as 'ready' because they require no calculation. This boosts libquantum and a few other workloads from the testsuite. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194346 91177308-0d34-0410-b5e6-96231b3b80d8
* SimplifyCFG: Don't duplicate calls to functions marked noduplicate v2Tom Stellard2013-10-21
| | | | | | | v2: - Use CI->cannotDuplicate() git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193115 91177308-0d34-0410-b5e6-96231b3b80d8
* Teach SimplifyCFG about address spacesMatt Arsenault2013-10-21
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193104 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix the predecessor removal logic in r193045.Michael Gottesman2013-10-21
| | | | | | Additionally some small comment/stylistic fixes are included as well. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193068 91177308-0d34-0410-b5e6-96231b3b80d8
* Teach simplify-cfg how to correctly create covered lookup tables for ↵Michael Gottesman2013-10-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | switches on iN with N >= 3. One optimization simplify-cfg performs is the converting of switches to lookup tables if the switch has > 4 cases. This is done by: 1. Finding the max/min case value and calculating the switch case range. 2. Create a lookup table basic block. 3. Perform a check in the switch's BB to see if the input value is in the switch's case range. If the input value satisfies said predicate branch to the lookup table BB, otherwise branch to the switch's default destination BB using the default value as the result. The conditional check consists of subtracting the min case value of the table from any input iN value and then ensuring that said value is unsigned less than the size of the lookup table represented as an iN value. If the lookup table is a covered lookup table, the size of the table will be N which is 0 as an iN value. Thus the comparison will be an `icmp ult` of an iN value against 0 which is always false yielding the incorrect result. This patch fixes this problem by recognizing if we have a covered lookup table and if we do, unconditionally jumps to the lookup table BB since the covering property of the lookup table implies no input values could not be handled by said BB. rdar://15268442 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193045 91177308-0d34-0410-b5e6-96231b3b80d8
* Provide basic type safety for array_pod_sort comparators.Benjamin Kramer2013-09-22
| | | | | | | | This makes using array_pod_sort significantly safer. The implementation relies on function pointer casting but that should be safe as we're dealing with void* here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191175 91177308-0d34-0410-b5e6-96231b3b80d8
* Use type helper functions.Matt Arsenault2013-09-06
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190113 91177308-0d34-0410-b5e6-96231b3b80d8
* Factor FlattenCFG out from SimplifyCFGTom Stellard2013-08-06
| | | | | | Patch by: Mei Ye git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187764 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix dereferencing end iterator in SimplifyCFG. Patch by Ye Mei.Alexey Samsonov2013-08-02
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187646 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix -Wdocumentation warnings.Rafael Espindola2013-07-28
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187336 91177308-0d34-0410-b5e6-96231b3b80d8
* SimplifyCFG: Use parallel-and and parallel-or mode to consolidate branch ↵Tom Stellard2013-07-27
| | | | | | | | | | | | | | conditions Merge consecutive if-regions if they contain identical statements. Both transformations reduce number of branches. The transformation is guarded by a target-hook, and is currently enabled only for +R600, but the correctness has been tested on X86 target using a variety of CPU benchmarks. Patch by: Mei Ye git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187278 91177308-0d34-0410-b5e6-96231b3b80d8
* Use SmallVectorImpl& instead of SmallVector to avoid repeating small vector ↵Craig Topper2013-07-14
| | | | | | size. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186274 91177308-0d34-0410-b5e6-96231b3b80d8
* SimplifyCFG: Teach switch generation some patterns that instcombine forms.Benjamin Kramer2013-07-04
| | | | | | | | This allows us to create switches even if instcombine has munged two of the incombing compares into one and some bit twiddling. This was motivated by enum compares that are common in clang. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185632 91177308-0d34-0410-b5e6-96231b3b80d8
* Second part of pr16069Rafael Espindola2013-06-04
| | | | | | | | | | | | | | | | | The problem this time seems to be a thinko. We were assuming that in the CFG A | \ | B | / C speculating the basic block B would cause only the phi value for the B->C edge to be speculated. That is not true, the phi's are semantically in the edges, so if the A->B->C path is taken, any code needed for A->C is not executed and we have to consider it too when deciding to speculate B. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183226 91177308-0d34-0410-b5e6-96231b3b80d8
* Typo: s/caes/cases/ in SimplifyCFGHans Wennborg2013-06-04
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183219 91177308-0d34-0410-b5e6-96231b3b80d8
* SimplifyCFG: Do not transform PHI to select if doing so would be unsafeDavid Majnemer2013-06-03
| | | | | | | | | | | | | | PR16069 is an interesting case where an incoming value to a PHI is a trap value while also being a 'ConstantExpr'. We do not consider this case when performing the 'HoistThenElseCodeToIf' optimization. Instead, make our modifications more conservative if we detect that we cannot transform the PHI to a select. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183152 91177308-0d34-0410-b5e6-96231b3b80d8
* SimplifyCFG: Small cleanup, use ICmpInst::isEquality()David Majnemer2013-06-03
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183151 91177308-0d34-0410-b5e6-96231b3b80d8
* SimplifyCFG: Fix typo in comment for ComputeSpeculationCostDavid Majnemer2013-06-01
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183078 91177308-0d34-0410-b5e6-96231b3b80d8
* More symbols that should be static.Benjamin Kramer2013-05-23
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182590 91177308-0d34-0410-b5e6-96231b3b80d8
* SimplifyCFG: If convert single conditional storesArnold Schwaighofer2013-04-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This resurrects r179957, but adds code that makes sure we don't touch atomic/volatile stores: This transformation will transform a conditional store with a preceeding uncondtional store to the same location: a[i] = may-alias with a[i] load if (cond) a[i] = Y into an unconditional store. a[i] = X may-alias with a[i] load tmp = cond ? Y : X; a[i] = tmp We assume that on average the cost of a mispredicted branch is going to be higher than the cost of a second store to the same location, and that the secondary benefits of creating a bigger basic block for other optimizations to work on outway the potential case where the branch would be correctly predicted and the cost of the executing the second store would be noticably reflected in performance. hmmer's execution time improves by 30% on an imac12,2 on ref data sets. With this change we are on par with gcc's performance (gcc also performs this transformation). There was a 1.2 % performance improvement on a ARM swift chip. Other tests in the test-suite+external seem to be mostly uninfluenced in my experiments: This optimization was triggered on 41 tests such that the executable was different before/after the patch. Only 1 out of the 40 tests (dealII) was reproducable below 100% (by about .4%). Given that hmmer benefits so much I believe this to be a fair trade off. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180731 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "SimplifyCFG: If convert single conditional stores"Arnold Schwaighofer2013-04-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is the temptation to make this tranform dependent on target information as it is not going to be beneficial on all (sub)targets. Therefore, we should probably do this in MI Early-Ifconversion. This reverts commit r179957. Original commit message: "SimplifyCFG: If convert single conditional stores This transformation will transform a conditional store with a preceeding uncondtional store to the same location: a[i] = may-alias with a[i] load if (cond) a[i] = Y into an unconditional store. a[i] = X may-alias with a[i] load tmp = cond ? Y : X; a[i] = tmp We assume that on average the cost of a mispredicted branch is going to be higher than the cost of a second store to the same location, and that the secondary benefits of creating a bigger basic block for other optimizations to work on outway the potential case were the branch would be correctly predicted and the cost of the executing the second store would be noticably reflected in performance. hmmer's execution time improves by 30% on an imac12,2 on ref data sets. With this change we are on par with gcc's performance (gcc also performs this transformation). There was a 1.2 % performance improvement on a ARM swift chip. Other tests in the test-suite+external seem to be mostly uninfluenced in my experiments: This optimization was triggered on 41 tests such that the executable was different before/after the patch. Only 1 out of the 40 tests (dealII) was reproducable below 100% (by about .4%). Given that hmmer benefits so much I believe this to be a fair trade off. I am going to watch performance numbers across the builtbots and will revert this if anything unexpected comes up." git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179980 91177308-0d34-0410-b5e6-96231b3b80d8
* SimplifyCFG: If convert single conditional storesArnold Schwaighofer2013-04-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This transformation will transform a conditional store with a preceeding uncondtional store to the same location: a[i] = may-alias with a[i] load if (cond) a[i] = Y into an unconditional store. a[i] = X may-alias with a[i] load tmp = cond ? Y : X; a[i] = tmp We assume that on average the cost of a mispredicted branch is going to be higher than the cost of a second store to the same location, and that the secondary benefits of creating a bigger basic block for other optimizations to work on outway the potential case were the branch would be correctly predicted and the cost of the executing the second store would be noticably reflected in performance. hmmer's execution time improves by 30% on an imac12,2 on ref data sets. With this change we are on par with gcc's performance (gcc also performs this transformation). There was a 1.2 % performance improvement on a ARM swift chip. Other tests in the test-suite+external seem to be mostly uninfluenced in my experiments: This optimization was triggered on 41 tests such that the executable was different before/after the patch. Only 1 out of the 40 tests (dealII) was reproducable below 100% (by about .4%). Given that hmmer benefits so much I believe this to be a fair trade off. I am going to watch performance numbers across the builtbots and will revert this if anything unexpected comes up. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179957 91177308-0d34-0410-b5e6-96231b3b80d8
* simplifycfg: Fix integer overflow converting switch into icmp.Hans Wennborg2013-04-16
| | | | | | | | | | | If a switch instruction has a case for every possible value of its type, with the same successor, SimplifyCFG would replace it with an icmp ult, but the computation of the bound overflows in that case, which inverts the test. Patch by Jed Davis! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179587 91177308-0d34-0410-b5e6-96231b3b80d8
* Don't remove a landing pad if the invoke requires a table entry.Bill Wendling2013-03-11
| | | | | | | | | An invoke may require a table entry. For instance, when the function it calls is expected to throw. <rdar://problem/13360379> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@176827 91177308-0d34-0410-b5e6-96231b3b80d8
* SimplifyCFG fix for volatile load/store.Andrew Trick2013-03-07
| | | | | | | | | | | | | Fixes rdar:13349374. Volatile loads and stores need to be preserved even if the language standard says they are undefined. "volatile" in this context means "get out of the way compiler, let my platform handle it". Additionally, this is the only way I know of with llvm to write to the first page (when hardware allows) without dropping to assembly. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@176599 91177308-0d34-0410-b5e6-96231b3b80d8
* Re-revert r173342, without losing the compile time improvements, flatChandler Carruth2013-01-27
| | | | | | out bug fixes, or functionality preserving refactorings. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173610 91177308-0d34-0410-b5e6-96231b3b80d8
* Switch this code away from Value::isUsedInBasicBlock. That code eitherChandler Carruth2013-01-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | loops over instructions in the basic block or the use-def list of the value, neither of which are really efficient when repeatedly querying about values in the same basic block. What's more, we already know that the CondBB is small, and so we can do a much more efficient test by counting the uses in CondBB, and seeing if those account for all of the uses. Finally, we shouldn't blanket fail on any such instruction, instead we should conservatively assume that those instructions are part of the cost. Note that this actually fixes a bug in the pass because isUsedInBasicBlock has a really terrible bug in it. I'll fix that in my next commit, but the fix for it would make this code suddenly take the compile time hit I thought it already was taking, so I wanted to go ahead and migrate this code to a faster & better pattern. The bug in isUsedInBasicBlock was also causing other tests to test the wrong thing entirely: for example we weren't actually disabling speculation for floating point operations as intended (and tested), but the test passed because we failed to speculate them due to the isUsedInBasicBlock failure. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173417 91177308-0d34-0410-b5e6-96231b3b80d8
* Reapply chandlerc's r173342 now that the miscompile it was triggering is fixed.Benjamin Kramer2013-01-24
| | | | | | | | | | | | | | | | | | | | | Original commit message: Plug TTI into the speculation logic, giving it a real cost interface that can be specialized by targets. The goal here is not to be more aggressive, but to just be more accurate with very obvious cases. There are instructions which are known to be truly free and which were not being modeled as such in this code -- see the regression test which is distilled from an inner loop of zlib. Everywhere the TTI cost model is insufficiently conservative I've added explicit checks with FIXME comments to go add proper modelling of these cost factors. If this causes regressions, the likely solution is to make TTI even more conservative in its cost estimates, but test cases will help here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173357 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert r173342 temporarily. It appears to cause a very late miscompileChandler Carruth2013-01-24
| | | | | | of stage2 in a bootstrap. Still investigating.... git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173343 91177308-0d34-0410-b5e6-96231b3b80d8
* Plug TTI into the speculation logic, giving it a real cost interfaceChandler Carruth2013-01-24
| | | | | | | | | | | | | | | | | | that can be specialized by targets. The goal here is not to be more aggressive, but to just be more accurate with very obvious cases. There are instructions which are known to be truly free and which were not being modeled as such in this code -- see the regression test which is distilled from an inner loop of zlib. Everywhere the TTI cost model is insufficiently conservative I've added explicit checks with FIXME comments to go add proper modelling of these cost factors. If this causes regressions, the likely solution is to make TTI even more conservative in its cost estimates, but test cases will help here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173342 91177308-0d34-0410-b5e6-96231b3b80d8
* Address a large chunk of this FIXME by accumulating the cost forChandler Carruth2013-01-24
| | | | | | | unfolded constant expressions rather than checking each one independently. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173341 91177308-0d34-0410-b5e6-96231b3b80d8
* Switch the constant expression speculation cost evaluation away fromChandler Carruth2013-01-24
| | | | | | | | | | | | | | | | | | | | a cost fuction that seems both a bit ad-hoc and also poorly suited to evaluating constant expressions. Notably, it is missing any support for trivial expressions such as 'inttoptr'. I could fix this routine, but it isn't clear to me all of the constraints its other users are operating under. The core protection that seems relevant here is avoiding the formation of a select instruction wich a further chain of select operations in a constant expression operand. Just explicitly encode that constraint. Also, update the comments and organization here to make it clear where this needs to go -- this should be driven off of real cost measurements which take into account the number of constants expressions and the depth of the constant expression tree. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173340 91177308-0d34-0410-b5e6-96231b3b80d8
* Rephrase the speculating scan of the conditional BB to be phrased inChandler Carruth2013-01-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | terms of cost rather than hoisting a single instruction. This does *not* change the cost model! We still set the cost threshold at 1 here, it's just that we track it by accumulating cost rather than by storing an instruction. The primary advantage is that we no longer leave no-op intrinsics in the basic block. For example, this will now move both debug info intrinsics and a single instruction, instead of only moving the instruction and leaving a basic block with nothing bug debug info intrinsics in it, and those intrinsics now no longer ordered correctly with the hoisted value. Instead, we now splice the entire conditional basic block's instruction sequence. This also places the code for checking the safety of hoisting next to the code computing the cost. Currently, the only observable side-effect of this change is that debug info intrinsics are no longer abandoned. I'm not sure how to craft a test case for this, and my real goal was the refactoring, but I'll talk to Dave or Eric about how to add a test case for this. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173339 91177308-0d34-0410-b5e6-96231b3b80d8
* Simplify the PHI node operand rewriting.Chandler Carruth2013-01-24
| | | | | | | | | | | | | | | | | | Previously, the code would scan the PHI nodes and build up a small setvector of candidate value pairs in phi nodes to go and rewrite. Once certain the rewrite could be performed, the code walks the set, and for each one re-scans the entire PHI node list looking for nodes to rewrite operands. Instead, scan the PHI nodes once to check for hazards, and then scan it a second time to rewrite the operands to selects. No set vector, and a max of two scans. The only downside is that we might form identical selects, but instcombine or anything else should fold those easily, and it seems unlikely to happen often. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173337 91177308-0d34-0410-b5e6-96231b3b80d8
* Give the basic block variables here names based on the if-then-endChandler Carruth2013-01-24
| | | | | | structure being analyzed. No functionality changed. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173334 91177308-0d34-0410-b5e6-96231b3b80d8
* Lift a cheap early exit test above loops and other complex early exitChandler Carruth2013-01-24
| | | | | | | | | tests. No need to pay the high cost when we're never going to do anything. No functionality changed. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173331 91177308-0d34-0410-b5e6-96231b3b80d8
* Spiff up the comment on this method, making the example a bit moreChandler Carruth2013-01-24
| | | | | | | | | | | pretty in doxygen, adding some of the details actually present in a classic example where this matters (a loop from gzip and many other compression algorithms), and a cautionary note about the risks inherent in the transform. This has come up on the mailing lists recently, and I suspect folks reading this code could benefit from going and looking at the MI pass that can really deal with these issues. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173329 91177308-0d34-0410-b5e6-96231b3b80d8
* Initialize the components of this class. Otherwise GCC thinks that Array may beDuncan Sands2013-01-23
| | | | | | | | | used uninitialized, since it fails to understand that Array is only used when SingleValue is not, and outputs a warning. It also seems generally safer given that the constructor is non-trivial and has plenty of early exits. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173242 91177308-0d34-0410-b5e6-96231b3b80d8
* Make SimplifyCFG simply depend upon TargetTransformInfo and pass itChandler Carruth2013-01-07
| | | | | | | | | | | | | through as a reference rather than a pointer. There is always *some* implementation of this available, so this simplifies code by not having to test for whether it is available or not. Further, it turns out there were piles of places where SimplifyCFG was recursing and not passing down either TD or TTI. These are fixed to be more pedantically consistent even though I don't have any particular cases where it would matter. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171691 91177308-0d34-0410-b5e6-96231b3b80d8
* Move TargetTransformInfo to live under the Analysis library. This noChandler Carruth2013-01-07
| | | | | | | longer would violate any dependency layering and it is in fact an analysis. =] git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171686 91177308-0d34-0410-b5e6-96231b3b80d8
* Switch SimplifyCFG over to the TargetTransformInfo interface rather thanChandler Carruth2013-01-05
| | | | | | the ScalarTargetTransformInfo interface. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171617 91177308-0d34-0410-b5e6-96231b3b80d8
* Move all of the header files which are involved in modelling the LLVM IRChandler Carruth2013-01-02
| | | | | | | | | | | | | | | | | | | | | into their new header subdirectory: include/llvm/IR. This matches the directory structure of lib, and begins to correct a long standing point of file layout clutter in LLVM. There are still more header files to move here, but I wanted to handle them in separate commits to make tracking what files make sense at each layer easier. The only really questionable files here are the target intrinsic tablegen files. But that's a battle I'd rather not fight today. I've updated both CMake and Makefile build systems (I think, and my tests think, but I may have missed something). I've also re-sorted the includes throughout the project. I'll be committing updates to Clang, DragonEgg, and Polly momentarily. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171366 91177308-0d34-0410-b5e6-96231b3b80d8
* Use the new script to sort the includes of every file under lib.Chandler Carruth2012-12-03
| | | | | | | | | | | | | | | | | Sooooo many of these had incorrect or strange main module includes. I have manually inspected all of these, and fixed the main module include to be the nearest plausible thing I could find. If you own or care about any of these source files, I encourage you to take some time and check that these edits were sensible. I can't have broken anything (I strictly added headers, and reordered them, never removed), but they may not be the headers you'd really like to identify as containing the API being implemented. Many forward declarations and missing includes were added to a header files to allow them to parse cleanly when included first. The main module rule does in fact have its merits. =] git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169131 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix non-determinism introduced in r168970 and pointed out by Duncan.Chandler Carruth2012-11-30
| | | | | | | | | | | | | We're iterating over a non-deterministically ordered container looking for two saturating flags. To do this correctly, we have to saturate both, and only stop looping if both saturate to their final value. Otherwise, which flag we see first changes the result. This is also a micro-optimization of the previous version as now we don't go into the (possibly expensive) test logic once the first violation of either constraint is detected. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168989 91177308-0d34-0410-b5e6-96231b3b80d8
* Rearrange the comments, control flow, and variable names; noChandler Carruth2012-11-30
| | | | | | | | | | | | | | functionality changed. Evan's commit r168970 moved the code that the primary comment in this function referred to to the other end of the function without moving the comment, and there has been a steady creep of "boolean" logic in it that is simpler if handled via early exit. That way each special case can have its own comments. I've also made the variable name a bit more explanatory than "AllFit". This is in preparation to fix the non-deterministic output of this function. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168988 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix logic to determine whether to turn a switch into a lookup table. WhenEvan Cheng2012-11-30
| | | | | | | | | | the tables cannot fit in registers (i.e. bitmap), do not emit the table if it's using an illegal type. rdar://12779436 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168970 91177308-0d34-0410-b5e6-96231b3b80d8
* SimplifyCFG: Don't assume non-null ScalarTargetTransformInfo.Hans Wennborg2012-11-16
| | | | | | Patch by Pekka Jääskeläinen! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168176 91177308-0d34-0410-b5e6-96231b3b80d8
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-11 20:06:10 +0000