summaryrefslogtreecommitdiff
path: root/lib/CodeGen/MachineBlockPlacement.cpp
Commit message (Collapse)AuthorAge
* Revert "Introduce a string_ostream string builder facilty"Alp Toker2014-06-26
| | | | | | Temporarily back out commits r211749, r211752 and r211754. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211814 91177308-0d34-0410-b5e6-96231b3b80d8
* Introduce a string_ostream string builder faciltyAlp Toker2014-06-26
| | | | | | | | | | | | | | | | | | | | string_ostream is a safe and efficient string builder that combines opaque stack storage with a built-in ostream interface. small_string_ostream<bytes> additionally permits an explicit stack storage size other than the default 128 bytes to be provided. Beyond that, storage is transferred to the heap. This convenient class can be used in most places an std::string+raw_string_ostream pair or SmallString<>+raw_svector_ostream pair would previously have been used, in order to guarantee consistent access without byte truncation. The patch also converts much of LLVM to use the new facility. These changes include several probable bug fixes for truncated output, a programming error that's no longer possible with the new interface. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211749 91177308-0d34-0410-b5e6-96231b3b80d8
* [Modules] Remove potential ODR violations by sinking the DEBUG_TYPEChandler Carruth2014-04-22
| | | | | | | | | | | | define below all header includes in the lib/CodeGen/... tree. While the current modules implementation doesn't check for this kind of ODR violation yet, it is likely to grow support for it in the future. It also removes one layer of macro pollution across all the included headers. Other sub-trees will follow. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206837 91177308-0d34-0410-b5e6-96231b3b80d8
* [C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper2014-04-14
| | | | | | instead of comparing to nullptr. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206142 91177308-0d34-0410-b5e6-96231b3b80d8
* Disable each MachineFunctionPass for 'optnone' functions, unless thatPaul Robinson2014-03-31
| | | | | | | | pass normally runs at optimization level None, or is part of the register allocation pipeline. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205228 91177308-0d34-0410-b5e6-96231b3b80d8
* [C++11] Add 'override' keyword to virtual methods that override their base ↵Craig Topper2014-03-07
| | | | | | class. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203220 91177308-0d34-0410-b5e6-96231b3b80d8
* [C++11] Replace llvm::next and llvm::prior with std::next and std::prev.Benjamin Kramer2014-03-02
| | | | | | Remove the old functions. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202636 91177308-0d34-0410-b5e6-96231b3b80d8
* Now that we have C++11, turn simple functors into lambdas and remove a ton ↵Benjamin Kramer2014-03-01
| | | | | | | | of boilerplate. No intended functionality change. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202588 91177308-0d34-0410-b5e6-96231b3b80d8
* Add a LLVM_DUMP_METHOD macro.Nico Weber2014-01-03
| | | | | | | | | | | | | | | | The motivation is to mark dump methods as used in debug builds so that they can be called from lldb, but to not do so in release builds so that they can be dead-stripped. There's lots of potential follow-up work suggested in the thread "Should dump methods be LLVM_ATTRIBUTE_USED only in debug builds?" on cfe-dev, but everyone seems to agreen on this subset. Macro name chosen by fair coin toss. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198456 91177308-0d34-0410-b5e6-96231b3b80d8
* [block-freq] Update MachineBlockPlacement and RegAllocGreedy to use the new ↵Michael Gottesman2013-12-14
| | | | | | MachineBlockFrequencyInfo methods. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197290 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix gcc warnings.Matt Arsenault2013-12-10
| | | | | | Unused variable and unused typedef in release build. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196947 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert part of GCC warning fix to fix debug build.Matt Arsenault2013-12-05
| | | | | | | The typedef is used inside the DEBUG(), and apparently can't be moved inside of it. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196528 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix minor GCC warnings.Matt Arsenault2013-12-05
| | | | | | Unused typedefs and unused variables. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196526 91177308-0d34-0410-b5e6-96231b3b80d8
* Output a bit more information in the debug printing for MBP. This wasChandler Carruth2013-11-25
| | | | | | useful when analyzing parts of zlib's behavior here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195588 91177308-0d34-0410-b5e6-96231b3b80d8
* MachineBlockPlacement: Strengthen the source order bias when picking an exit ↵Benjamin Kramer2013-11-20
| | | | | | | | | | | | | | | | | | | | | | | | | block. We now only allow breaking source order if the exit block frequency is significantly higher than the other exit block. The actual bias is currently under a flag so the best cut-off can be found; the flag defaults to the old behavior. The idea is to get some benchmark coverage over different values for the flag and pick the best one. When we require the new frequency to be at least 20% higher than the old frequency I see a 5% speedup on zlib's deflate when compressing a random file on x86_64/westmere. Hal reported a small speedup on Fhourstones on a BG/Q and no regressions in the test suite. The test case is the full long_match function from zlib's deflate. I was reluctant to add it for previous tweaks to branch probabilities because it's large and potentially fragile, but changed my mind since it's an important use case and more likely to break with all the current work going into the PGO infrastructure. Differential Revision: http://llvm-reviews.chandlerc.com/D2202 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195265 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix a defect in code-layout pass, improving Benchmarks/Olden/em3d/em3d by ↵Shuxin Yang2013-06-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | about 30% (4.58s vs 3.2s on an oldish Mac Tower). The corresponding src is excerpted bellow. The lopp accounts for about 90% of execution time. -------------------- cat -n test-suite/MultiSource/Benchmarks/Olden/em3d/make_graph.c 90 91 for (k=0; k<j; k++) 92 if (other_node == cur_node->to_nodes[k]) break; The defective layout is sketched bellow, where the two branches need to swap. ------------------------------------------------------------------------ L: ... if (cond) goto out-of-loop goto L While this code sequence is defective, I don't understand why it incurs 1/3 of execution time. CPU-event-profiling indicates the poor laoyout dose not increase in br-misprediction; it dosen't increase stall cycle at all, and it dosen't prevent the CPU detect the loop (i.e. Loop-Stream-Detector seems to be working fine as well)... The root cause of the problem is that the layout pass calls AnalyzeBranch() with basic-block which is not updated to reflect its current layout. rdar://13966341 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183174 91177308-0d34-0410-b5e6-96231b3b80d8
* Don't disable block layout when forcing block alignment.Nadav Rotem2013-04-12
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179355 91177308-0d34-0410-b5e6-96231b3b80d8
* Add a flag to align all basic blocks in the function.Nadav Rotem2013-04-12
| | | | | | | | | | | | When debugging performance regressions we often ask ourselves if the regression that we see is due to poor isel/sched/ra or due to some micro-architetural problem. When comparing two code sequences one good way to rule out front-end bottlenecks (and other the issues) is to force code alignment. This pass adds a flag that forces the alignment of all of the basic blocks in the program. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179353 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix a typoNadav Rotem2013-03-29
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178346 91177308-0d34-0410-b5e6-96231b3b80d8
* Split TargetLowering into a CodeGen and a SelectionDAG part.Benjamin Kramer2013-01-11
| | | | | | | | | This fixes some of the cycles between libCodeGen and libSelectionDAG. It's still a complete mess but as long as the edges consist of virtual call it doesn't cause breakage. BasicTTI did static calls and thus broke some build configurations. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172246 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove the Function::getFnAttributes method in favor of using the AttributeSetBill Wendling2012-12-30
| | | | | | | | | | directly. This is in preparation for removing the use of the 'Attribute' class as a collection of attributes. That will shift to the AttributeSet class instead. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171253 91177308-0d34-0410-b5e6-96231b3b80d8
* Rename the 'Attributes' class to 'Attribute'. It's going to represent a ↵Bill Wendling2012-12-19
| | | | | | single attribute in the future. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170502 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
* Create enums for the different attributes.Bill Wendling2012-10-09
| | | | | | | | We use the enums to query whether an Attributes object has that attribute. The opaque layer is responsible for knowing where that specific attribute is stored. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165488 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove the `hasFnAttr' method from Function.Bill Wendling2012-09-26
| | | | | | | | The hasFnAttr method has been replaced by querying the Attributes explicitly. No intended functionality change. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164725 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove silly dead store. Patch by Ettl Martin.Duncan Sands2012-09-14
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163882 91177308-0d34-0410-b5e6-96231b3b80d8
* Add a much more conservative strategy for aligning branch targets.Chandler Carruth2012-08-07
| | | | | | | | | | | | | Previously, MBP essentially aligned every branch target it could. This bloats code quite a bit, especially non-looping code which has no real reason to prefer aligned branch targets so heavily. As Andy said in review, it's still a bit odd to do this without a real cost model, but this at least has much more plausible heuristics. Fixes PR13265. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161409 91177308-0d34-0410-b5e6-96231b3b80d8
* Reverse order of the two branches at end of a basic block if it is profitable.Manman Ren2012-07-31
| | | | | | | | | | | | | | | | We branch to the successor with higher edge weight first. Convert from je LBB4_8 --> to outer loop jmp LBB4_14 --> to inner loop to jne LBB4_14 jmp LBB4_8 PR12750 rdar: 11393714 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161018 91177308-0d34-0410-b5e6-96231b3b80d8
* Update a bunch of stale comments that dated from when this folled theChandler Carruth2012-06-26
| | | | | | | very first (and worst) placement algorithm. These should now more accurately reflect the reality of the pass. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159185 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix typos found by http://github.com/lyda/misspell-checkBenjamin Kramer2012-06-02
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@157885 91177308-0d34-0410-b5e6-96231b3b80d8
* Add a somewhat hacky heuristic to do something different from whole-loopChandler Carruth2012-04-16
| | | | | | | | | | | | | rotation. When there is a loop backedge which is an unconditional branch, we will end up with a branch somewhere no matter what. Try placing this backedge in a fallthrough position above the loop header as that will definitely remove at least one branch from the loop iteration, where whole loop rotation may not. I haven't seen any benchmarks where this is important but loop-blocks.ll tests for it, and so this will be covered when I flip the default. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154812 91177308-0d34-0410-b5e6-96231b3b80d8
* Tweak the loop rotation logic to check whether the loop is naturallyChandler Carruth2012-04-16
| | | | | | | | | | | laid out in a form with a fallthrough into the header and a fallthrough out of the bottom. In that case, leave the loop alone because any rotation will introduce unnecessary branches. If either side looks like it will require an explicit branch, then the rotation won't add any, do it to ensure the branch occurs outside of the loop (if possible) and maximize the benefit of the fallthrough in the bottom. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154806 91177308-0d34-0410-b5e6-96231b3b80d8
* Rewrite how machine block placement handles loop rotation.Chandler Carruth2012-04-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a complex change that resulted from a great deal of experimentation with several different benchmarks. The one which proved the most useful is included as a test case, but I don't know that it captures all of the relevant changes, as I didn't have specific regression tests for each, they were more the result of reasoning about what the old algorithm would possibly do wrong. I'm also failing at the moment to craft more targeted regression tests for these changes, if anyone has ideas, it would be welcome. The first big thing broken with the old algorithm is the idea that we can take a basic block which has a loop-exiting successor and a looping successor and use the looping successor as the layout top in order to get that particular block to be the bottom of the loop after layout. This happens to work in many cases, but not in all. The second big thing broken was that we didn't try to select the exit which fell into the nearest enclosing loop (to which we exit at all). As a consequence, even if the rotation worked perfectly, it would result in one of two bad layouts. Either the bottom of the loop would get fallthrough, skipping across a nearer enclosing loop and thereby making it discontiguous, or it would be forced to take an explicit jump over the nearest enclosing loop to earch its successor. The point of the rotation is to get fallthrough, so we need it to fallthrough to the nearest loop it can. The fix to the first issue is to actually layout the loop from the loop header, and then rotate the loop such that the correct exiting edge can be a fallthrough edge. This is actually much easier than I anticipated because we can handle all the hard parts of finding a viable rotation before we do the layout. We just store that, and then rotate after layout is finished. No inner loops get split across the post-rotation backedge because we check for them when selecting the rotation. That fix exposed a latent problem with our exitting block selection -- we should allow the backedge to point into the middle of some inner-loop chain as there is no real penalty to it, the whole point is that it *won't* be a fallthrough edge. This may have blocked the rotation at all in some cases, I have no idea and no test case as I've never seen it in practice, it was just noticed by inspection. Finally, all of these fixes, and studying the loops they produce, highlighted another problem: in rotating loops like this, we sometimes fail to align the destination of these backwards jumping edges. Fix this by actually walking the backwards edges rather than relying on loopinfo. This fixes regressions on heapsort if block placement is enabled as well as lots of other cases where the previous logic would introduce an abundance of unnecessary branches into the execution. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154783 91177308-0d34-0410-b5e6-96231b3b80d8
* Make a somewhat subtle change in the logic of block placement. SometimesChandler Carruth2012-04-10
| | | | | | | | | | | | | | | | the loop header has a non-loop predecessor which has been pre-fused into its chain due to unanalyzable branches. In this case, rotating the header into the body of the loop in order to place a loop exit at the bottom of the loop is a Very Bad Idea as it makes the loop non-contiguous. I'm working on a good test case for this, but it's a bit annoynig to craft. I should get one shortly, but I'm submitting this now so I can begin the (lengthy) performance analysis process. An initial run of LNT looks really, really good, but there is too much noise there for me to trust it much. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154395 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove an over zealous assert. The assert was trying to catch placesChandler Carruth2012-04-08
| | | | | | | | | | | | | | | | | | | | | | | | | | where a chain outside of the loop block-set ended up in the worklist for scheduling as part of the contiguous loop. However, asserting the first block in the chain is in the loop-set isn't a valid check -- we may be forced to drag a chain into the worklist due to one block in the chain being part of the loop even though the first block is *not* in the loop. This occurs when we have been forced to form a chain early due to un-analyzable branches. No test case here as I have no idea how to even begin reducing one, and it will be hopelessly fragile. We have to somehow end up with a loop header of an inner loop which is a successor of a basic block with an unanalyzable pair of branch instructions. Ow. Self-host triggers it so it is unlikely it will regress. This at least gets block placement back to passing selfhost and the test suite. There are still a lot of slowdown that I don't like coming out of block placement, although there are now also a lot of speedups. =[ I'm seeing swings in both directions up to 10%. I'm going to try to find time to dig into this and see if we can turn this on for 3.1 as it does a really good job of cleaning up after some loops that degraded with the inliner changes. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154287 91177308-0d34-0410-b5e6-96231b3b80d8
* Add a debug-only 'dump' method to the BlockChain structure to easeChandler Carruth2012-04-08
| | | | | | debugging. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154286 91177308-0d34-0410-b5e6-96231b3b80d8
* Codegen pass definition cleanup. No functionality.Andrew Trick2012-02-08
| | | | | | | | | | | | | Moving toward a uniform style of pass definition to allow easier target configuration. Globally declare Pass ID. Globally declare pass initializer. Use INITIALIZE_PASS consistently. Add a call to the initializer from CodeGen.cpp. Remove redundant "createPass" functions and "getPassName" methods. While cleaning up declarations, cleaned up comments (sorry for large diff). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@150100 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert patch from 147090. There is not point to make code less readable if weJakub Staszak2011-12-21
| | | | | | | don't get any serious benefit there. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147101 91177308-0d34-0410-b5e6-96231b3b80d8
* - Change a few operator[] to lookup which is cheaper.Jakub Staszak2011-12-21
| | | | | | | - Add some constantness. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147090 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove unneeded semicolon.Jakub Staszak2011-12-07
| | | | | | | Skip two looking up at BlockChain. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146053 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove unneeded type.Jakub Staszak2011-12-07
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145995 91177308-0d34-0410-b5e6-96231b3b80d8
* - Remove unneeded #includes.Jakub Staszak2011-12-06
| | | | | | | | - Remove unused types/fields. - Add some constantness. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145993 91177308-0d34-0410-b5e6-96231b3b80d8
* Prevent rotating the blocks of a loop (and thus getting a backedge to beChandler Carruth2011-11-27
| | | | | | | | | | | | | | fallthrough) in cases where we might fail to rotate an exit to an outer loop onto the end of the loop chain. Having *some* rotation, but not performing this rotation, is the primary fix of thep performance regression with -enable-block-placement for Olden/em3d (a whopping 30% regression). Still working on reducing the test case that actually exercises this and the new rotation strategy out of this code, but I want to check if this regresses other test cases first as that may indicate it isn't the correct fix. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145195 91177308-0d34-0410-b5e6-96231b3b80d8
* Take two on rotating the block ordering of loops. My previous attemptChandler Carruth2011-11-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | was centered around the premise of laying out a loop in a chain, and then rotating that chain. This is good for preserving contiguous layout, but bad for actually making sane rotations. In order to keep it safe, I had to essentially make it impossible to rotate deeply nested loops. The information needed to correctly reason about a deeply nested loop is actually available -- *before* we layout the loop. We know the inner loops are already fused into chains, etc. We lose information the moment we actually lay out the loop. The solution was the other alternative for this algorithm I discussed with Benjamin and some others: rather than rotating the loop after-the-fact, try to pick a profitable starting block for the loop's layout, and then use our existing layout logic. I was worried about the complexity of this "pick" step, but it turns out such complexity is needed to handle all the important cases I keep teasing out of benchmarks. This is, I'm afraid, a bit of a work-in-progress. It is still misbehaving on some likely important cases I'm investigating in Olden. It also isn't really tested. I'm going to try to craft some interesting nested-loop test cases, but it's likely to be extremely time consuming and I don't want to go there until I'm sure I'm testing the correct behavior. Sadly I can't come up with a way of getting simple, fine grained test cases for this logic. We need complex loop structures to even trigger much of it. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145183 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix an impressive type-o / spell-o Duncan noticed.Chandler Carruth2011-11-27
| | | | git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145181 91177308-0d34-0410-b5e6-96231b3b80d8
* Rework a bit of the implementation of loop block rotation to not rely soChandler Carruth2011-11-27
| | | | | | | | | | | | | | | heavily on AnalyzeBranch. That routine doesn't behave as we want given that rotation occurs mid-way through re-ordering the function. Instead merely check that there are not unanalyzable branching constructs present, and then reason about the CFG via successor lists. This actually simplifies my mental model for all of this as well. The concrete result is that we now will rotate more loop chains. I've added a test case from Olden highlighting the effect. There is still a bit more to do here though in order to regain all of the performance in Olden. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145179 91177308-0d34-0410-b5e6-96231b3b80d8
* Introduce a loop block rotation optimization to the new block placementChandler Carruth2011-11-27
| | | | | | | | | | | | | | | pass. This is designed to achieve one of the important optimizations that the old code placement pass did, but more simply. This is a somewhat rough and *very* conservative version of the transform. We could get a lot fancier here if there are profitable cases to do so. In particular, this only looks for a single pattern, it insists that the loop backedge being rotated away is the last backedge in the chain, and it doesn't provide any means of doing better in-loop placement due to the rotation. However, it appears that it will handle the important loops I am finding in the LLVM test suite. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145158 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix a silly use-after-free issue. A much earlier version of this codeChandler Carruth2011-11-24
| | | | | | | | | | | | need lots of fanciness around retaining a reference to a Chain's slot in the BlockToChain map, but that's all gone now. We can just go directly to allocating the new chain (which will update the mapping for us) and using it. Somewhat gross mechanically generated test case replicates the issue Duncan spotted when actually testing this out. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145120 91177308-0d34-0410-b5e6-96231b3b80d8
* When adding blocks to the list of those which no longer have any CFGChandler Carruth2011-11-24
| | | | | | | | | | | | | | conflicts, we should only be adding the first block of the chain to the list, lest we try to merge into the middle of that chain. Most of the places we were doing this we already happened to be looking at the first block, but there is no reason to assume that, and in some cases it was clearly wrong. I've added a couple of tests here. One already worked, but I like having an explicit test for it. The other is reduced from a test case Duncan reduced for me and used to crash. Now it is handled correctly. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145119 91177308-0d34-0410-b5e6-96231b3b80d8
* Relax an invariant that block placement was trying to assert a bitChandler Carruth2011-11-23
| | | | | | | | | | | further. This invariant just wasn't going to work in the face of unanalyzable branches; we need to be resillient to the phenomenon of chains poking into a loop and poking out of a loop. In fact, we already were, we just needed to not assert on it. This was found during a bootstrap with block placement turned on. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145100 91177308-0d34-0410-b5e6-96231b3b80d8
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-23 08:52:06 +0000