summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/MachineOutliner.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Fix Wdocumentation warning. NFCI.Simon Pilgrim2020-01-101-2/+0
|
* [MachineOutliner][AArch64] Save + restore LR in noreturn functionsJessica Paquette2020-01-071-6/+0
| | | | | | | | | | | | | | Conservatively always save + restore LR in noreturn functions. These functions do not end in a RET, and so they aren't guaranteed to have an instruction which uses LR in any way. So, as a result, you can end up in unfortunate situations where you can't backtrace out of these functions in a debugger. Remove the old noreturn test, and add a new one which is more descriptive. Remove the restriction that we can't outline from noreturn functions as well since we now do the right thing.
* [NFC][MachineOutliner] Rewrite setSuffixIndices to be iterativeJessica Paquette2019-12-201-18/+25
| | | | | | | | Having this function be recursive could use up way too much stack space. Rewrite it as an iterative traversal in the tree instead to prevent this. Fixes PR44344.
* Sink all InitializePasses.h includesReid Kleckner2019-11-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This file lists every pass in LLVM, and is included by Pass.h, which is very popular. Every time we add, remove, or rename a pass in LLVM, it caused lots of recompilation. I found this fact by looking at this table, which is sorted by the number of times a file was changed over the last 100,000 git commits multiplied by the number of object files that depend on it in the current checkout: recompiles touches affected_files header 342380 95 3604 llvm/include/llvm/ADT/STLExtras.h 314730 234 1345 llvm/include/llvm/InitializePasses.h 307036 118 2602 llvm/include/llvm/ADT/APInt.h 213049 59 3611 llvm/include/llvm/Support/MathExtras.h 170422 47 3626 llvm/include/llvm/Support/Compiler.h 162225 45 3605 llvm/include/llvm/ADT/Optional.h 158319 63 2513 llvm/include/llvm/ADT/Triple.h 140322 39 3598 llvm/include/llvm/ADT/StringRef.h 137647 59 2333 llvm/include/llvm/Support/Error.h 131619 73 1803 llvm/include/llvm/Support/FileSystem.h Before this change, touching InitializePasses.h would cause 1345 files to recompile. After this change, touching it only causes 550 compiles in an incremental rebuild. Reviewers: bkramer, asbirlea, bollu, jdoerfert Differential Revision: https://reviews.llvm.org/D70211
* Remove redundant assignment. NFCI.Simon Pilgrim2019-11-051-1/+0
| | | | Fixes cppcheck warning.
* Use iterator prefix increment. NFCI.Simon Pilgrim2019-11-051-1/+1
|
* [MachineOutliner] Reduce scope of variable and stop duplicate getMF() calls. ↵Simon Pilgrim2019-11-051-3/+3
| | | | NFCI.
* [MachineOutliner] Fix uninitialized variable warnings. NFCI.Simon Pilgrim2019-11-051-1/+1
|
* [NFC][MachineOutliner] Fix typo in commentDavid Tellenbach2019-10-301-1/+1
|
* [MachineOutliner][NFC] clang-formating the MachineOutliner.Puyan Lotfi2019-10-281-34/+27
|
* [MachineOuliner][NFC] Refactoring code to make outline rerunning a cleaner diff.Puyan Lotfi2019-10-281-7/+19
| | | | | | | | I want to add the ability to rerun the outliner in certain cases, and I thought this could be an NFC change that could make a subsequent change that allows for rerunning the outliner a cleaner diff. Differential Revision: https://reviews.llvm.org/D69482
* [DebugInfo][If-Converter] Update call site info during the optimizationNikola Prica2019-10-081-1/+1
| | | | | | | | | | | | | | During the If-Converter optimization pay attention when copying or deleting call instructions in order to keep call site information in valid state. Reviewers: aprantl, vsk, efriedma Reviewed By: vsk, efriedma Differential Revision: https://reviews.llvm.org/D66955 llvm-svn: 374068
* [MachineOutliner] Disable outlining from noreturn functionsJessica Paquette2019-10-041-0/+6
| | | | | | | | | | | | | | | | Outlining from noreturn functions doesn't do the correct thing right now. The outliner should respect that the caller is marked noreturn. In the event that we have a noreturn function, and the outlined code is in tail position, the outliner will not see that the outlined function should be tail called. As a result, you end up with a regular call containing a return. Fixing this requires that we check that all candidates live inside noreturn functions. So, for the sake of correctness, don't outline from noreturn functions right now. Add machine-outliner-noreturn.mir to test this. llvm-svn: 373791
* [NewPM] Port MachineModuleInfo to the new pass manager.Yuanfang Chen2019-09-301-4/+4
| | | | | | | | | | | | | Existing clients are converted to use MachineModuleInfoWrapperPass. The new interface is for defining a new pass manager API in CodeGen. Reviewers: fedor.sergeev, philip.pfaffe, chandlerc, arsenm Reviewed By: arsenm, fedor.sergeev Differential Revision: https://reviews.llvm.org/D64183 llvm-svn: 373240
* [Backend] Keep call site info valid through the backendDjordje Todorovic2019-06-271-4/+8
| | | | | | | | | | | | | | | | | | | | Handle call instruction replacements and deletions in order to preserve valid state of the call site info of the MachineFunction. NOTE: If the call site info is enabled for a new target, the assertion from the MachineFunction::DeleteMachineInstr() should help to locate places where the updateCallSiteInfo() should be called in order to preserve valid state of the call site info. ([10/13] Introduce the debug entry values.) Co-authored-by: Ananth Sowda <asowda@cisco.com> Co-authored-by: Nikola Prica <nikola.prica@rt-rk.com> Co-authored-by: Ivan Baev <ibaev@cisco.com> Differential Revision: https://reviews.llvm.org/D61062 llvm-svn: 364536
* Use llvm::stable_sortFangrui Song2019-04-231-5/+4
| | | | | | While touching the code, simplify if feasible. llvm-svn: 358996
* [MachineOutliner] Replace ostringstream based string concatenation with TwineFangrui Song2019-04-101-10/+4
| | | | | | | | This makes my libLLVMCodeGen.so.9svn 4936 bytes smaller. While here, delete unused #include <map> llvm-svn: 358089
* [opaque pointer types] Add a FunctionCallee wrapper type, and use it.James Y Knight2019-02-011-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc doesn't choke on it, hopefully. Original Message: The FunctionCallee type is effectively a {FunctionType*,Value*} pair, and is a useful convenience to enable code to continue passing the result of getOrInsertFunction() through to EmitCall, even once pointer types lose their pointee-type. Then: - update the CallInst/InvokeInst instruction creation functions to take a Callee, - modify getOrInsertFunction to return FunctionCallee, and - update all callers appropriately. One area of particular note is the change to the sanitizer code. Previously, they had been casting the result of `getOrInsertFunction` to a `Function*` via `checkSanitizerInterfaceFunction`, and storing that. That would report an error if someone had already inserted a function declaraction with a mismatching signature. However, in general, LLVM allows for such mismatches, as `getOrInsertFunction` will automatically insert a bitcast if needed. As part of this cleanup, cause the sanitizer code to do the same. (It will call its functions using the expected signature, however they may have been declared.) Finally, in a small number of locations, callers of `getOrInsertFunction` actually were expecting/requiring that a brand new function was being created. In such cases, I've switched them to Function::Create instead. Differential Revision: https://reviews.llvm.org/D57315 llvm-svn: 352827
* Revert "[opaque pointer types] Add a FunctionCallee wrapper type, and use it."James Y Knight2019-01-311-3/+3
| | | | | | | | | This reverts commit f47d6b38c7a61d50db4566b02719de05492dcef1 (r352791). Seems to run into compilation failures with GCC (but not clang, where I tested it). Reverting while I investigate. llvm-svn: 352800
* [opaque pointer types] Add a FunctionCallee wrapper type, and use it.James Y Knight2019-01-311-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The FunctionCallee type is effectively a {FunctionType*,Value*} pair, and is a useful convenience to enable code to continue passing the result of getOrInsertFunction() through to EmitCall, even once pointer types lose their pointee-type. Then: - update the CallInst/InvokeInst instruction creation functions to take a Callee, - modify getOrInsertFunction to return FunctionCallee, and - update all callers appropriately. One area of particular note is the change to the sanitizer code. Previously, they had been casting the result of `getOrInsertFunction` to a `Function*` via `checkSanitizerInterfaceFunction`, and storing that. That would report an error if someone had already inserted a function declaraction with a mismatching signature. However, in general, LLVM allows for such mismatches, as `getOrInsertFunction` will automatically insert a bitcast if needed. As part of this cleanup, cause the sanitizer code to do the same. (It will call its functions using the expected signature, however they may have been declared.) Finally, in a small number of locations, callers of `getOrInsertFunction` actually were expecting/requiring that a brand new function was being created. In such cases, I've switched them to Function::Create instead. Differential Revision: https://reviews.llvm.org/D57315 llvm-svn: 352791
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Fix Wdocumentation warning. NFCI.Simon Pilgrim2018-12-061-2/+0
| | | | llvm-svn: 348517
* [MachineOutliner][NFC] Move yet another std::vector out of a loopJessica Paquette2018-12-061-3/+4
| | | | | | | | Once again, following the wisdom of the LLVM Programmer's Manual. I think that's enough refactoring for today. :) llvm-svn: 348439
* [MachineOutliner][NFC] Move std::vector out of loopJessica Paquette2018-12-061-1/+2
| | | | | | See http://llvm.org/docs/ProgrammersManual.html#vector llvm-svn: 348433
* [MachineOutliner][NFC] Remove IntegerInstructionMap from InstructionMapperJessica Paquette2018-12-061-9/+2
| | | | | | | | | | Refactoring. This map was only used when we used a string of integers to output the outlined sequence. Since it's no longer used for anything, there's no reason to keep it around. llvm-svn: 348432
* [MachineOutliner][NFC] Remove buildCandidateList and replace with findCandidatesJessica Paquette2018-12-051-45/+9
| | | | | | | | | | | | | | More refactoring. Since the pruning logic has changed, and the candidate list is gone, everything can be sunk into findCandidates. We no longer need to keep track of the length of the longest substring, so we can drop all of that logic as well. After this, we just find all of the candidates and move to outlining. llvm-svn: 348428
* [MachineOutliner][NFC] Candidates don't need to be shared_ptrs anymoreJessica Paquette2018-12-051-11/+10
| | | | | | | | | | | More refactoring. After the changes to the pruning logic, and removing CandidateList, there's no reason for Candiates to be shared_ptrs (or pointers at all). std::shared_ptr<Candidate> -> Candidate. llvm-svn: 348427
* [MachineOutliner][NFC] Remove CandidateList, since it's now unused.Jessica Paquette2018-12-051-29/+11
| | | | | | | After removing the pruning logic, there's no reason to populate a list of Candidates. Remove CandidateList and update comments. llvm-svn: 348422
* Fix buildbot capture warningJessica Paquette2018-12-051-9/+6
| | | | | | | | | | | | | A bot didn't like my lambda. This ought to fix it. Example: http://lab.llvm.org:8011/builders/lld-x86_64-win7/builds/30139/steps/build%20lld/logs/stdio error C3493: 'AlreadyRemoved' cannot be implicitly captured because no default capture mode has been specified llvm-svn: 348421
* [MachineOutliner][NFC] Simplify and unify pruning/outlining logicJessica Paquette2018-12-051-157/+15
| | | | | | | | | | | | | | Since we're now performing outlining per OutlinedFunction rather than per Candidate, we can simply outline each candidate as it shows up. Instead of having a pruning phase, instead, we'll outline entire functions. Then we'll update the UnsignedVec we mapped to reflect the deletion. If any candidate is in a space that's marked dirty, then we'll drop it. This lets us remove the pruning logic entirely, and greatly simplifies the code. llvm-svn: 348420
* [MachineOutliner] Outline functions by order of benefitJessica Paquette2018-12-051-63/+68
| | | | | | | | | | | | | | | | | | Mostly NFC, only change is the order of outlined function names. Loop over the outlined functions instead of walking the candidate list. This is a bit easier to understand. It's far more natural to create a function, then replace all of its occurrences with calls than the other way around. The functions outlined after this do not change, but their names will be decided by their benefit. E.g, OUTLINED_FUNCTION_0 will now always be the most beneficial function, rather than the first one seen. This makes it easier to enforce an ordering on the outlined functions. So, this also adds a test to make sure that the ordering works as expected. llvm-svn: 348414
* [MachineOutliner][NFC] Don't create outlined sequence from integer mappingJessica Paquette2018-12-051-13/+6
| | | | | | | | | | | Some gardening/refactoring. It's cleaner to copy the instructions into the MachineFunction using the first candidate instead of going to the mapper. Also, by doing this we can remove the Seq member from OutlinedFunction entirely. llvm-svn: 348390
* Fix Wdocumentation warning. NFCI.Simon Pilgrim2018-11-191-1/+1
| | | | llvm-svn: 347253
* [DebugInfo] DISubprogram flags get their own flags word. NFC.Paul Robinson2018-11-191-2/+3
| | | | | | | | | | | | | This will hold flags specific to subprograms. In the future we could potentially free up scarce bits in DIFlags by moving subprogram-specific flags from there to the new flags word. This patch does not change IR/bitcode formats, that will be done in a follow-up. Differential Revision: https://reviews.llvm.org/D54597 llvm-svn: 347239
* [MachineOutliner][NFC] Check if CandidatesForRepeatedSeq < 2Jessica Paquette2018-11-151-1/+1
| | | | | | There's no reason to call getOutliningCandidateInfo with a single candidate. llvm-svn: 346913
* [MachineOutliner][NFC] Use MBB flags to avoid call checks in getOutliningInfoJessica Paquette2018-11-131-2/+9
| | | | | | | | | | | | | We already determine a bunch of information about an MBB in getMachineOutlinerMBBFlags. We can reuse that information to avoid calculating things that must be false/true. The first thing we can easily check is if an outlined sequence could ever contain calls. There's no reason to walk over the outlined range, checking for calls, if we already know that there are no calls in the block containing the sequence. llvm-svn: 346809
* [MachineOutliner][NFC] Exit getOutliningType if there are < 2 candidatesJessica Paquette2018-11-131-2/+3
| | | | | | | Since we never outline anything with fewer than 2 occurrences, there's no reason to compute cost model information if there's less than that. llvm-svn: 346803
* Fix uninitialized variable.Alexander Kornienko2018-11-131-1/+1
| | | | | | | | | | | | | | | | Flags variable was not initialized and later used (both isMBBSafeToOutlineFrom implementations assume it's initialized), which breaks test/CodeGen/AArch64/machine-outliner.mir. under memory sanitizer: MemorySanitizer: use-of-uninitialized-value #0 in llvm::AArch64InstrInfo::getOutliningType(llvm::MachineInstrBundleIterator<llvm::MachineInstr, false>&, unsigned int) const llvm/lib/Target/AArch64/AArch64InstrInfo.cpp:5494:9 #1 in (anonymous namespace)::InstructionMapper::convertToUnsignedVec(llvm::MachineBasicBlock&, llvm::TargetInstrInfo const&) llvm/lib/CodeGen/MachineOutliner.cpp:772:19 #2 in (anonymous namespace)::MachineOutliner::populateMapper((anonymous namespace)::InstructionMapper&, llvm::Module&, llvm::MachineModuleInfo&) llvm/lib/CodeGen/MachineOutliner.cpp:1543:14 #3 in (anonymous namespace)::MachineOutliner::runOnModule(llvm::Module&) llvm/lib/CodeGen/MachineOutliner.cpp:1645:3 #4 in (anonymous namespace)::MPPassManager::runOnModule(llvm::Module&) llvm/lib/IR/LegacyPassManager.cpp:1744:27 #5 in llvm::legacy::PassManagerImpl::run(llvm::Module&) llvm/lib/IR/LegacyPassManager.cpp:1857:44 #6 in compileModule(char**, llvm::LLVMContext&) llvm/tools/llc/llc.cpp:597:8 llvm-svn: 346761
* [MachineOutliner][NFC] Change getMachineOutlinerMBBFlags to ↵Jessica Paquette2018-11-121-1/+6
| | | | | | | | | | | | isMBBSafeToOutlineFrom Instead of returning Flags, return true if the MBB is safe to outline from. This lets us check for unsafe situations, like say, in AArch64, X17 is live across a MBB without being defined in that MBB. In that case, there's no point in performing an instruction mapping. llvm-svn: 346718
* [MachineOutliner][NFC] Early exit pruning when candidates don't share an MBBJessica Paquette2018-11-121-0/+8
| | | | | | | | | | There's no way they can overlap in this case. This can save a few iterations when the candidate is close to the beginning of a MachineBasicBlock. It's particularly useful when the average length of a MachineBasicBlock in the program is small. llvm-svn: 346682
* [MachineOutliner][NFC] Put suffix tree in buildCandidateListJessica Paquette2018-11-121-6/+5
| | | | | | It's only used there, so it doesn't make much sense to have it in runOnModule. llvm-svn: 346681
* [MachineOutliner][NFC] Only map blocks which have adjacent legal instructionsJessica Paquette2018-11-081-14/+36
| | | | | | | | | | | If a block doesn't have any ranges of adjacent legal instructions, then it can't have outlining candidates. There's no point in mapping legal isntructions in situations like this. I noticed this reduces the size of the suffix tree in sqlite3 for AArch64 at -Oz by about 3%. llvm-svn: 346379
* [MachineOutliner][NFC] Don't map MBBs that don't contain legal instructionsJessica Paquette2018-11-081-18/+47
| | | | | | | | | | | | | | I noticed that there are lots of basic blocks that don't have enough legal instructions in them to warrant outlining. We can skip mapping these entirely. In sqlite3, compiled for AArch64 at -Oz, this results in a 10% reduction of the total nodes in the suffix tree. These nodes can never be part of a repeated substring, and so they don't impact the result at all. Before this, there were 62128 nodes in the tree for sqlite3. After this, there are 56457 nodes. llvm-svn: 346373
* [MachineOutliner][NFC] Remove Parent field from SuffixTreeNodeJessica Paquette2018-11-071-28/+14
| | | | | | | | | | This is only used for calculating ConcatLen. This isn't necessary, since it's easily derived from the traversal setting suffix indices. Remove that. Rename CurrIdx to CurrNodeLen to better describe what's going on. llvm-svn: 346349
* [MachineOutliner][NFC] Traverse suffix tree using a RepeatedSubstring iteratorJessica Paquette2018-11-071-53/+111
| | | | | | | | | This takes the traversal methods introduced in r346269 and adapts them into an iterator. This allows the outliner to iterate over repeated substrings within the suffix tree directly without having to initially find all of the substrings and then iterate over them after you've found them. llvm-svn: 346345
* [MachineOutliner] Don't store outlined function numberings on OutlinedFunctionJessica Paquette2018-11-071-5/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | NFC-ish. This doesn't change the behaviour of the outliner, but does make sure that you won't end up with say OUTLINED_FUNCTION_2: ... ret OUTLINED_FUNCTION_248: ... ret as the only outlined functions in your module. Those should really be OUTLINED_FUNCTION_0: ... ret OUTLINED_FUNCTION_1: ... ret If we produce outlined functions, they probably should have sequential numbers attached to them. This makes it a bit easier+stable to write outliner tests. The point of this is to move towards a bit more stability in outlined function names. By doing this, we at least don't rely on the traversal order of the suffix tree. Instead, we rely on the order of the candidate list, which is *far* more consistent. The candidate list is ordered by the end indices of candidates, so we're more likely to get a stable ordering. This is still susceptible to changes in the cost model though (like, if we suddenly find new candidates, for example). llvm-svn: 346340
* [MachineOutliner][NFC] Remove OccurrenceCount from SuffixTreeNodeJessica Paquette2018-11-061-7/+0
| | | | | | After changing the way we find candidates in r346269, this is no longer used. llvm-svn: 346275
* [MachineOutliner][NFC] Remove IsInTree from SuffixTreeNodeJessica Paquette2018-11-061-4/+0
| | | | | | | After changing the way we find repeated substrings in r346269, this field is no longer used by anything, so it can be removed. llvm-svn: 346274
* [MachineOutliner][NFC] Add findRepeatedSubstrings to SuffixTree, kill LeafVectorJessica Paquette2018-11-061-87/+106
| | | | | | | | | | | | | | | | | | | | | Instead of iterating over the leaves to find repeated substrings, and walking collecting leaf children when we don't necessarily need them, let's just calculate what we need and iterate over that. By doing this, we don't have to save every leaf. It's easier to read the code too and understand what's going on. The goal here, at the end of the day, is to set up to allow us to do something like for (RepeatedSubstring &RS : ST) { ... do stuff with RS ... } Which would let us perform the cost model stuff and the repeated substring query at the same time. llvm-svn: 346269
* [MachineOutliner][NFC] Remember when you map something illegal across MBBsJessica Paquette2018-11-011-20/+27
| | | | | | | | | | | | | | | | | | | | | Instruction mapping in the outliner uses "illegal numbers" to signify that something can't ever be part of an outlining candidate. This means that the number is unique and can't be part of any repeated substring. Because each of these is unique, we can use a single unique number to represent a range of things we can't outline. The outliner tries to leverage this using a flag which is set in an MBB when the previous instruction we tried to map was "illegal". This patch improves that logic to work across MBBs. As a bonus, this also simplifies the mapping logic somewhat. This also updates the machine-outliner-remarks test, which was impacted by the order of Candidates on an OutlinedFunction changing. This order isn't guaranteed, so I added a FIXME to fix that in a follow-up. The order of Candidates on an OutlinedFunction isn't important, so this still is NFC. llvm-svn: 345906
OpenPOWER on IntegriCloud