summaryrefslogtreecommitdiffstats
path: root/llvm/test/Transforms/SimplifyCFG/switch-dead-default.ll
Commit message (Collapse)AuthorAgeFilesLines
* [SimplifyCFG] NFC, update Switch tests as a baseline.Shawn Landden2019-06-131-39/+130
| | | | | | | | | | | | | Also add baseline tests to show effect of later patches. There were a couple of regressions here that were never caught, but my patch set that this is a preparation to will fix them. This is the third attempt to land this patch. Differential Revision: https://reviews.llvm.org/D61150 llvm-svn: 363319
* [SimplifyCFG] reverting preliminary Switch patches againShawn Landden2019-06-131-130/+39
| | | | | | | | | This reverts 363226 and 363227, both NFC intended I swear I fixed the test case that is failing, and ran the tests, but I will look into it again. llvm-svn: 363229
* [SimplifyCFG] NFC, update Switch tests to better examine successive patchesShawn Landden2019-06-131-39/+130
| | | | | | | | | | | Also add baseline tests to show effect of later patches. There were a couple of regressions here that were never caught, but my patch set that this is a preparation to will fix them. Differential Revision: https://reviews.llvm.org/D61150 llvm-svn: 363226
* [SimplifyCFG] revert the last commit.Shawn Landden2019-06-131-123/+39
| | | | | | I ran ALL the test suite locally, so I will look into this... llvm-svn: 363223
* [SimplifyCFG] NFC, update Switch tests to HEAD so I canShawn Landden2019-06-131-39/+123
| | | | | | | | | | see if my changes change anything Also add baseline tests to show effect of later patches. Differential Revision: https://reviews.llvm.org/D61150 llvm-svn: 363222
* [SimplifyCFG] fix last commitShawn Landden2019-06-041-0/+3
| | | | llvm-svn: 362501
* [SimplifyCFG] NFC; remove bogus test caseShawn Landden2019-06-041-26/+0
| | | | | | | | | | Even if one bit is defined, the code is not clear what it is suppose to do. The test wants to assert that some bits are undef, but that's not what the IR does and I don't think it's even possible to do that in any meaningful way. It was added in D12497, so @reames might want to double check. Differential Revision: https://reviews.llvm.org/D60859 llvm-svn: 362499
* [SimplifyCFG] back out all SwitchInst commitsShawn Landden2019-05-261-149/+42
| | | | | | | | They caused the sanitizer builds to fail. My suspicion is the change the countLeadingZeros(). llvm-svn: 361736
* [SimplifyCFG] Run ReduceSwitchRange unconditionally, generalizeShawn Landden2019-05-261-29/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rather than gating on "isSwitchDense" (resulting in necessesarily sparse lookup tables even when they were generated), always run this quite cheap transform. This transform is useful not just for generating tables. LowerSwitch also wants this: read LowerSwitch.cpp:257. Be careful to not generate worse code, by introducing a SubThreshold heuristic. Instead of just sorting by signed, generalize the finding of the best base. And now that it is run unconditionally, do not replicate its functionality in SwitchToLookupTable (which could use a Sub when having a hole is smaller, hence the SubThreshold heuristic located in a single place). This simplifies SwitchToLookupTable, and fixes some ugly corner cases due to the use of signed numbers, such as a table containing i16 32768 and 32769, of which 32769 would be interpreted as -32768, and now the code thinks the table is size 65536. (We still use unconditional subtraction when building a single-register mask, but I think this whole block should go when the more general sparse map is added, which doesn't leave empty holes in the table.) And the reason test4 and test5 did not trigger was documented wrong: it was because they were not considered sufficiently "dense". Also, fix generation of invalid LLVM-IR: shl by bit-width. llvm-svn: 361727
* [SimplifyCFG] NFC, update Switch tests to HEAD so I can see if my changes ↵Shawn Landden2019-05-261-42/+127
| | | | | | | | change anything Also add baseline tests to show effect of later patches. llvm-svn: 361725
* Revert "Temporarily Revert "Add basic loop fusion pass.""Eric Christopher2019-04-171-0/+179
| | | | | | | | The reversion apparently deleted the test/Transforms directory. Will be re-reverting again. llvm-svn: 358552
* Temporarily Revert "Add basic loop fusion pass."Eric Christopher2019-04-171-179/+0
| | | | | | | | As it's causing some bot failures (and per request from kbarton). This reverts commit r358543/ab70da07286e618016e78247e4a24fcb84077fda. llvm-svn: 358546
* Revert @llvm.assume with operator bundles (r289755-r289757)Daniel Jasper2016-12-191-4/+4
| | | | | | | This creates non-linear behavior in the inliner (see more details in r289755's commit thread). llvm-svn: 290086
* Make processing @llvm.assume more efficient by using operand bundlesHal Finkel2016-12-151-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | There was an efficiency problem with how we processed @llvm.assume in ValueTracking (and other places). The AssumptionCache tracked all of the assumptions in a given function. In order to find assumptions relevant to computing known bits, etc. we searched every assumption in the function. For ValueTracking, that means that we did O(#assumes * #values) work in InstCombine and other passes (with a constant factor that can be quite large because we'd repeat this search at every level of recursion of the analysis). Several of us discussed this situation at the last developers' meeting, and this implements the discussed solution: Make the values that an assume might affect operands of the assume itself. To avoid exposing this detail to frontends and passes that need not worry about it, I've used the new operand-bundle feature to add these extra call "operands" in a way that does not affect the intrinsic's signature. I think this solution is relatively clean. InstCombine adds these extra operands based on what ValueTracking, LVI, etc. will need and then those passes need only search the users of the values under consideration. This should fix the computational-complexity problem. At this point, no passes depend on the AssumptionCache, and so I'll remove that as a follow-up change. Differential Revision: https://reviews.llvm.org/D27259 llvm-svn: 289755
* [SimplifyCFG] Use known bits to eliminate dead switch defaultsPhilip Reames2015-09-101-4/+96
| | | | | | | | | | | | This is a follow up to http://reviews.llvm.org/D11995 implementing the suggestion by Hans. If we know some of the bits of the value being switched on, we know that the maximum number of unique cases covers the unknown bits. This allows to eliminate switch defaults for large integers (i32) when most bits in the value are known. Note that I had to make the transform contingent on not having any dead cases. This is conservatively correct with the old code, but required for the new code since we might have a dead case which varies one of the known bits. Counting that towards our number of covering cases would be bad. If we do have dead cases, we'll eliminate them first, then revisit the possibly dead default. Differential Revision: http://reviews.llvm.org/D12497 llvm-svn: 247309
* [SimplifyCFG] Prune code from a provably unreachable switch defaultPhilip Reames2015-08-261-0/+87
As Sanjoy pointed out over in http://reviews.llvm.org/D11819, a switch on an icmp should always be able to become a branch instruction. This patch generalizes that notion slightly to prove that the default case of a switch is unreachable if the cases completely cover all possible bit patterns in the condition. Once that's done, the switch to branch conversion kicks in just fine. Note: Duplicate case values are disallowed by the LangRef and verifier. Differential Revision: http://reviews.llvm.org/D11995 llvm-svn: 246125
OpenPOWER on IntegriCloud