summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/MachineOutliner.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [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
* [MachineOutliner] Inherit target features from parent functionJessica Paquette2018-10-291-0/+8
| | | | | | | | | | | | | | | If a function has target features, it may contain instructions that aren't represented in the default set of instructions. If the outliner pulls out one of these instructions, and the function doesn't have the right attributes attached, we'll run into an LLVM error explaining that the target doesn't support the necessary feature for the instruction. This makes outlined functions inherit target features from their parents. It also updates the machine-outliner.ll test to check that we're properly inheriting target features. llvm-svn: 345535
* [MachineOutliner][NFC] Don't add MBBs with a size < 2 to the search spaceJessica Paquette2018-09-201-1/+5
| | | | | | | | | | | The suffix tree won't ever consider sequences with a length less than 2. Therefore, we really ought to not even consider them in the first place. Also add a FIXME explaining that this should be defined in terms of the size in B of an outlined call versus the size in B of the MBB. llvm-svn: 342688
* [MachineOutliner][NFC] Move debug info emission to createOutlinedFunctionJessica Paquette2018-09-201-35/+23
| | | | | | | | | When you create an outlined function, you know everything you need to know to decide if debug info should be created. If we emit debug info in createOutlinedFunction, then we don't need to keep track of every IR function we create. llvm-svn: 342677
* [MachineOutliner][NFC] Don't map more illegal instrs than you have toJessica Paquette2018-09-171-0/+11
| | | | | | | | | | | | | | | We were mapping an instruction every time we saw something we couldn't map before this. Since each illegal mapping is unique, we only have to do this once. This makes it so that we don't map illegal instructions when the previous mapped instruction was illegal. In CTMark (AArch64), this results in 240 fewer instruction mappings on average over 619 files in total. The largest improvement is 12576 fewer mappings in one file, and the smallest is 0. The median improvement is 101 fewer mappings. llvm-svn: 342405
* [MachineOutliner] Add codegen size remarks to the MachineOutlinerJessica Paquette2018-09-111-1/+103
| | | | | | | | | | | | | | | | Since the outliner is a module pass, it doesn't get codegen size remarks like the other codegen passes do. This adds size remarks *to* the outliner. This is kind of a workaround, so it's peppered with FIXMEs; size remarks really ought to not ever be handled by the pass itself. However, since the outliner is the only "MachineModulePass", this works for now. Since the entire purpose of the MachineOutliner is to produce code size savings, it really ought to be included in codgen size remarks. If we ever go ahead and make a MachineModulePass (say, something similar to MachineFunctionPass), then all of this ought to be moved there. llvm-svn: 342009
* [MachineOutliner][NFC] Factor out instruction mapping into its own functionJessica Paquette2018-09-111-28/+38
| | | | | | | Just some tidy-up. Pull the mapper stuff into `populateMapper`. This makes it a bit easier to read what's going on in `runOnModule`. llvm-svn: 341959
* [MI] Change the array of `MachineMemOperand` pointers to beChandler Carruth2018-08-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a generically extensible collection of extra info attached to a `MachineInstr`. The primary change here is cleaning up the APIs used for setting and manipulating the `MachineMemOperand` pointer arrays so chat we can change how they are allocated. Then we introduce an extra info object that using the trailing object pattern to attach some number of MMOs but also other extra info. The design of this is specifically so that this extra info has a fixed necessary cost (the header tracking what extra info is included) and everything else can be tail allocated. This pattern works especially well with a `BumpPtrAllocator` which we use here. I've also added the basic scaffolding for putting interesting pointers into this, namely pre- and post-instruction symbols. These aren't used anywhere yet, they're just there to ensure I've actually gotten the data structure types correct. I'll flesh out support for these in a subsequent patch (MIR dumping, parsing, the works). Finally, I've included an optimization where we store any single pointer inline in the `MachineInstr` to avoid the allocation overhead. This is expected to be the overwhelmingly most common case and so should avoid any memory usage growth due to slightly less clever / dense allocation when dealing with >1 MMO. This did require several ergonomic improvements to the `PointerSumType` to reasonably support the various usage models. This also has a side effect of freeing up 8 bits within the `MachineInstr` which could be repurposed for something else. The suggested direction here came largely from Hal Finkel. I hope it was worth it. ;] It does hopefully clear a path for subsequent extensions w/o nearly as much leg work. Lots of thanks to Reid and Justin for careful reviews and ideas about how to do all of this. Differential Revision: https://reviews.llvm.org/D50701 llvm-svn: 339940
* [MachineOutliner] Clean up subtarget handling.Eli Friedman2018-08-011-23/+22
| | | | | | | | | | | | | | Call shouldOutlineFromFunctionByDefault, isFunctionSafeToOutlineFrom, getOutliningType, and getMachineOutlinerMBBFlags using the correct TargetInstrInfo. And don't create a MachineFunction for a function declaration. The call to getOutliningCandidateInfo is still a little weird, but at least the weirdness is explicitly called out. Differential Revision: https://reviews.llvm.org/D49880 llvm-svn: 338465
* Remove trailing spaceFangrui Song2018-07-301-1/+1
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338293
* [MachineOutliner] Exit getOutliningCandidateInfo when we erase all candidatesJessica Paquette2018-07-271-1/+7
| | | | | | | | | | There was a missing check for if a candidate list was entirely deleted. This adds that check. This fixes an asan failure caused by running test/CodeGen/AArch64/addsub_ext.ll with the MachineOutliner enabled. llvm-svn: 338148
* [MachineOutliner][NFC] Move outlined function remark into its own functionJessica Paquette2018-07-241-31/+33
| | | | | | | This pulls the OutlinedFunction remark out into its own function to make the code a bit easier to read. llvm-svn: 337849
* [MachineOutliner][NFC] Move target frame info into OutlinedFunctionJessica Paquette2018-07-241-5/+4
| | | | | | | | | | | | | | Just some gardening here. Similar to how we moved call information into Candidates, this moves outlined frame information into OutlinedFunction. This allows us to remove TargetCostInfo entirely. Anywhere where we returned a TargetCostInfo struct, we now return an OutlinedFunction. This establishes OutlinedFunctions as more of a general repeated sequence, and Candidates as occurrences of those repeated sequences. llvm-svn: 337848
* [MachineOutliner][NFC] Make Candidates own their call informationJessica Paquette2018-07-241-1/+1
| | | | | | | | | | | | | Before this, TCI contained all the call information for each Candidate. This moves that information onto the Candidates. As a result, each Candidate can now supply how it ought to be called. Thus, Candidates will be able to, say, call the same function in cheaper ways when possible. This also removes that information from TCI, since it's no longer used there. A follow-up patch for the AArch64 outliner will demonstrate this. llvm-svn: 337840
* [MachineOutliner][NFC] Move missed opt remark into its own functionJessica Paquette2018-07-241-39/+46
| | | | | | | | Having the missed remark code in the middle of `findCandidates` made the function hard to follow. This yanks that out into a new function, `emitNotOutliningCheaperRemark`. llvm-svn: 337839
* [MachineOutliner][NFC] Sink some candidate logic into OutlinedFunctionJessica Paquette2018-07-241-15/+6
| | | | | | | | | | | | | | | | | Just some simple gardening to improve clarity. Before, we had something along the lines of 1) Create a std::vector of Candidates 2) Create an OutlinedFunction 3) Create a std::vector of pointers to Candidates 4) Copy those over to the OutlinedFunction and the Candidate list Now, OutlinedFunctions create the Candidate pointers. They're still copied over to the main list of Candidates, but it makes it a bit clearer what's going on. llvm-svn: 337838
* [MachineOutliner] Check the last instruction from the sequence when updating ↵Francis Visoiu Mistrih2018-07-141-1/+1
| | | | | | | | | | | | | | | | | liveness The MachineOutliner was doing an std::for_each from the call (inserted before the outlined sequence) to the iterator at the end of the sequence. std::for_each needs the iterator past the end, so the last instruction was not taken into account when propagating the liveness information. This fixes the machine verifier issue in machine-outliner-disubprogram.ll. Differential Revision: https://reviews.llvm.org/D49295 llvm-svn: 337090
* [MachineOutliner] Fix typo in getOutliningCandidateInfo function nameYvan Roux2018-07-041-1/+1
| | | | | | | | getOutlininingCandidateInfo -> getOutliningCandidateInfo Differential Revision: https://reviews.llvm.org/D48867 llvm-svn: 336285
OpenPOWER on IntegriCloud