summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Utils/CodeExtractor.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [IR] Add Instruction::isLifetimeStartOrEnd, NFCVedant Kumar2018-12-211-2/+1
| | | | | | | | | | | Instruction::isLifetimeStartOrEnd() checks whether an Instruction is an llvm.lifetime.start or an llvm.lifetime.end intrinsic. This was suggested as a cleanup in D55967. Differential Revision: https://reviews.llvm.org/D56019 llvm-svn: 349964
* [CodeExtractor] Store outputs at the first valid insertion pointVedant Kumar2018-12-071-12/+12
| | | | | | | | | | | | | | | | | | | | | | | | When CodeExtractor outlines values which are used by the original function, it must store those values in some in-out parameter. This store instruction must not be inserted in between a PHI and an EH pad instruction, as that results in invalid IR. This fixes the following verifier failure seen while outlining within ObjC methods with live exit values: The unwind destination does not have an exception handling instruction! %call35 = invoke i8* bitcast (i8* (i8*, i8*, ...)* @objc_msgSend to i8* (i8*, i8*)*)(i8* %exn.adjusted, i8* %1) to label %invoke.cont34 unwind label %lpad33, !dbg !4183 The unwind destination does not have an exception handling instruction! invoke void @objc_exception_throw(i8* %call35) #12 to label %invoke.cont36 unwind label %lpad33, !dbg !4184 LandingPadInst not the first non-PHI instruction in the block. %3 = landingpad { i8*, i32 } catch i8* null, !dbg !1411 rdar://46540815 llvm-svn: 348562
* [CodeExtractor] Do not marked outlined calls which may resume EH as noreturnVedant Kumar2018-12-051-2/+5
| | | | | | | | | | Treat terminators which resume exception propagation as returning instructions (at least, for the purposes of marking outlined functions `noreturn`). This is to avoid inserting traps after calls to outlined functions which unwind. rdar://46129950 llvm-svn: 348404
* [CodeExtractor] Split PHI nodes with incoming values from outlined region ↵Vedant Kumar2018-12-031-49/+90
| | | | | | | | | | | | | | | | | (PR39433) If a PHI node out of extracted region has multiple incoming values from it, split this PHI on two parts. First PHI has incomings only from region and extracts with it (they are placed to the separate basic block that added to the list of outlined), and incoming values in original PHI are replaced by first PHI. Similar solution is already used in CodeExtractor for PHIs in entry block (severSplitPHINodes method). It covers PR39433 bug. Patch by Sergei Kachkov! Differential Revision: https://reviews.llvm.org/D55018 llvm-svn: 348205
* [CodeExtractor] Mark functions noreturn when applicableVedant Kumar2018-11-081-0/+7
| | | | | | | | | | This eliminates the outlining penalty for llvm.trap/unreachable, because callers no longer have to emit cleanup/ret instructions after calling an outlined `noreturn` function. rdar://45523626 llvm-svn: 346421
* [CodeExtractor] Do not extract calls to eh_typeid_for (PR39545)Vedant Kumar2018-11-061-3/+11
| | | | | | | | | | | The lowering for a call to eh_typeid_for changes when it's moved from one function to another. There are several proposals for fixing this issue in llvm.org/PR39545. Until some solution is in place, do not allow CodeExtractor to extract calls to eh_typeid_for, as that results in serious miscompilations. llvm-svn: 346256
* [CodeExtractor] Erase use-without-def debug intrinsics in parent funcVedant Kumar2018-11-061-0/+9
| | | | | | | | | | | When CodeExtractor moves instructions to a new function, debug intrinsics referring to those instructions within the parent function become invalid. This results in the same verifier failure which motivated r344545, about function-local metadata being used in the wrong function. llvm-svn: 346255
* [HotColdSplitting] Identify larger cold regions using domtree queriesVedant Kumar2018-10-241-16/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current splitting algorithm works in three stages: 1) Identify cold blocks, then 2) Use forward/backward propagation to mark hot blocks, then 3) Grow a SESE region of blocks *outside* of the set of hot blocks and start outlining. While testing this pass on Apple internal frameworks I noticed that some kinds of control flow (e.g. loops) are never outlined, even though they unconditionally lead to / follow cold blocks. I noticed two other issues related to how cold regions are identified: - An inconsistency can arise in the internal state of the hotness propagation stage, as a block may end up in both the ColdBlocks set and the HotBlocks set. Further inconsistencies can arise as these sets do not match what's in ProfileSummaryInfo. - It isn't necessary to limit outlining to single-exit regions. This patch teaches the splitting algorithm to identify maximal cold regions and outline them. A maximal cold region is defined as the set of blocks post-dominated by a cold sink block, or dominated by that sink block. This approach can successfully outline loops in the cold path. As a side benefit, it maintains less internal state than the current approach. Due to a limitation in CodeExtractor, blocks within the maximal cold region which aren't dominated by a single entry point (a so-called "max ancestor") are filtered out. Results: - X86 (LNT + -Os + externals): 134KB of TEXT were outlined compared to 47KB pre-patch, or a ~3x improvement. Did not see a performance impact across two runs. - AArch64 (LNT + -Os + externals + Apple-internal benchmarks): 149KB of TEXT were outlined. Ditto re: performance impact. - Outlining results improve marginally in the internal frameworks I tested. Follow-ups: - Outline more than once per function, outline large single basic blocks, & try to remove unconditional branches in outlined functions. Differential Revision: https://reviews.llvm.org/D53627 llvm-svn: 345209
* [hot-cold-split] Name split functions with ".cold" suffixTeresa Johnson2018-10-241-5/+11
| | | | | | | | | | | | | | | | | | | | | | | Summary: The current default of appending "_"+entry block label to the new extracted cold function breaks demangling. Change the deliminator from "_" to "." to enable demangling. Because the header block label will be empty for release compile code, use "extracted" after the "." when the label is empty. Additionally, add a mechanism for the client to pass in an alternate suffix applied after the ".", and have the hot cold split pass use "cold."+Count, where the Count is currently 1 but can be used to uniquely number multiple cold functions split out from the same function with D53588. Reviewers: sebpop, hiraditya Subscribers: llvm-commits, erik.pilkington Differential Revision: https://reviews.llvm.org/D53534 llvm-svn: 345178
* [TI removal] Update CodeExtractor to use Instruction directly.Chandler Carruth2018-10-181-4/+4
| | | | llvm-svn: 344716
* [CodeExtractor] Erase debug intrinsics in outlined thunks (fix PR22900)Vedant Kumar2018-10-151-0/+13
| | | | | | | | | | | | | | | Variable updates within the outlined function are invisible to debuggers. This could be improved by defining a DISubprogram for the new function. For the moment, simply erase the debug intrinsics instead. This fixes verifier failures about function-local metadata being used in the wrong function, seen while testing the hot/cold splitting pass. rdar://45142482 Differential Revision: https://reviews.llvm.org/D53267 llvm-svn: 344545
* [TI removal] Make variables declared as `TerminatorInst` and initializedChandler Carruth2018-10-151-4/+4
| | | | | | | | | | | | | by `getTerminator()` calls instead be declared as `Instruction`. This is the biggest remaining chunk of the usage of `getTerminator()` that insists on the narrow type and so is an easy batch of updates. Several files saw more extensive updates where this would cascade to requiring API updates within the file to use `Instruction` instead of `TerminatorInst`. All of these were trivial in nature (pervasively using `Instruction` instead just worked). llvm-svn: 344502
* [x86/SLH] Add a real Clang flag and LLVM IR attribute for SpeculativeChandler Carruth2018-09-041-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Load Hardening. Wires up the existing pass to work with a proper IR attribute rather than just a hidden/internal flag. The internal flag continues to work for now, but I'll likely remove it soon. Most of the churn here is adding the IR attribute. I talked about this Kristof Beyls and he seemed at least initially OK with this direction. The idea of using a full attribute here is that we *do* expect at least some forms of this for other architectures. There isn't anything *inherently* x86-specific about this technique, just that we only have an implementation for x86 at the moment. While we could potentially expose this as a Clang-level attribute as well, that seems like a good question to defer for the moment as it isn't 100% clear whether that or some other programmer interface (or both?) would be best. We'll defer the programmer interface side of this for now, but at least get to the point where the feature can be enabled without relying on implementation details. This also allows us to do something that was really hard before: we can enable *just* the indirect call retpolines when using SLH. For x86, we don't have any other way to mitigate indirect calls. Other architectures may take a different approach of course, and none of this is surfaced to user-level flags. Differential Revision: https://reviews.llvm.org/D51157 llvm-svn: 341363
* Allow creating llvm::Function in non-zero address spacesAlexander Richardson2018-08-231-4/+3
| | | | | | | | | | | | | | | | | | | | Most users won't have to worry about this as all of the 'getOrInsertFunction' functions on Module will default to the program address space. An overload has been added to Function::Create to abstract away the details for most callers. This is based on https://reviews.llvm.org/D37054 but without the changes to make passing a Module to Function::Create() mandatory. I have also added some more tests and fixed the LLParser to accept call instructions for types in the program address space. Reviewed By: bjope Differential Revision: https://reviews.llvm.org/D47541 llvm-svn: 340519
* [CodeExtractor] Use 'normal destination' BB as insert point to store invoke ↵Florian Hahn2018-08-211-1/+9
| | | | | | | | | | | | | | | | | | | results. Currently CodeExtractor tries to use the next node after an invoke to place the store for the result of the invoke, if it is an out parameter of the region. This fails, as the invoke terminates the current BB. In that case, we can place the store in the 'normal destination' BB, as the result will only be available in that case. Reviewers: davidxl, davide, efriedma Reviewed By: davidxl Differential Revision: https://reviews.llvm.org/D51037 llvm-svn: 340331
* Remove trailing spaceFangrui Song2018-07-301-3/+3
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338293
* Rename DEBUG macro to LLVM_DEBUG.Nicola Zaghen2018-05-141-10/+11
| | | | | | | | | | | | | | | | The DEBUG() macro is very generic so it might clash with other projects. The renaming was done as follows: - git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g' - git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM - Manual change to APInt - Manually chage DOCS as regex doesn't match it. In the transition period the DEBUG() macro is still present and aliased to the LLVM_DEBUG() one. Differential Revision: https://reviews.llvm.org/D43624 llvm-svn: 332240
* [CodeExtractor] Allow extracting blocks with exception handlingSergey Dmitriev2018-05-111-27/+91
| | | | | | | | | | | | | | | | | This is a CodeExtractor improvement which adds support for extracting blocks which have exception handling constructs if that is legal to do. CodeExtractor performs validation checks to ensure that extraction is legal when it finds invoke instructions or EH pads (landingpad, catchswitch, or cleanuppad) in blocks to be extracted. I have also added an option to allow extraction of blocks with alloca instructions, but no validation is done for allocas. CodeExtractor caller has to validate it himself before allowing alloca instructions to be extracted. By default allocas are still not allowed in extraction blocks. Differential Revision: https://reviews.llvm.org/D45904 llvm-svn: 332151
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-011-2/+2
| | | | | | | | | | | | | | | | We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46290 llvm-svn: 331272
* Add the ShadowCallStack attributeVlad Tsyrklevich2018-04-031-0/+1
| | | | | | | | | | | | | | | | | | Summary: Introduce the ShadowCallStack function attribute. It's added to functions compiled with -fsanitize=shadow-call-stack in order to mark functions to be instrumented by a ShadowCallStack pass to be submitted in a separate change. Reviewers: pcc, kcc, kubamracek Reviewed By: pcc, kcc Subscribers: cryptoad, mehdi_amini, javed.absar, llvm-commits, kcc Differential Revision: https://reviews.llvm.org/D44800 llvm-svn: 329108
* [SimplifyCFG] Create attribute for fuzzing-specific optimizations.Matt Morehouse2018-03-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | Summary: When building with libFuzzer, converting control flow to selects or obscuring the original operands of CMPs reduces the effectiveness of libFuzzer's heuristics. This patch provides an attribute to disable or modify certain optimizations for optimal fuzzing signal. Provides a less aggressive alternative to https://reviews.llvm.org/D44057. Reviewers: vitalybuka, davide, arsenm, hfinkel Reviewed By: vitalybuka Subscribers: junbuml, mehdi_amini, wdng, javed.absar, hiraditya, llvm-commits, kcc Differential Revision: https://reviews.llvm.org/D44232 llvm-svn: 328214
* [X86] Added support for nocf_check attribute for indirect Branch TrackingOren Ben Simhon2018-03-171-0/+1
| | | | | | | | | | | | | | | X86 Supports Indirect Branch Tracking (IBT) as part of Control-Flow Enforcement Technology (CET). IBT instruments ENDBR instructions used to specify valid targets of indirect call / jmp. The `nocf_check` attribute has two roles in the context of X86 IBT technology: 1. Appertains to a function - do not add ENDBR instruction at the beginning of the function. 2. Appertains to a function pointer - do not track the target function of this pointer by adding nocf_check prefix to the indirect-call instruction. This patch implements `nocf_check` context for Indirect Branch Tracking. It also auto generates `nocf_check` prefixes before indirect branchs to jump tables that are guarded by range checks. Differential Revision: https://reviews.llvm.org/D41879 llvm-svn: 327767
* Add a ProfileCount class to represent entry counts.Easwaran Raman2018-01-171-4/+5
| | | | | | | | | | | | | | Summary: The class wraps a uint64_t and an enum to represent the type of profile count (real and synthetic) with some helper methods. Reviewers: davidxl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D41883 llvm-svn: 322771
* [CodeExtractor] Use subset of function attributes for extracted function.Florian Hahn2018-01-071-4/+74
| | | | | | | | | | | | | | | | | | | | | | | | In addition to target-dependent attributes, we can also preserve a white-listed subset of target independent function attributes. The white-list excludes problematic attributes, most prominently: * attributes related to memory accesses, as alloca instructions could be moved in/out of the extracted block * control-flow dependent attributes, like no_return or thunk, as the relerelevant instructions might or might not get extracted. Thanks @efriedma and @aemerson for providing a set of attributes that cannot be propagated. Reviewers: efriedma, davidxl, davide, silvas Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D41334 llvm-svn: 321961
* [CodeExtractor] Add debug locations for new call and branch instrs.Florian Hahn2017-12-081-1/+24
| | | | | | | | | | | | | | | | | | | | | | | Summary: If a partially inlined function has debug info, we have to add debug locations to the call instruction calling the outlined function. We use the debug location of the first instruction in the outlined function, as the introduced call transfers control to this statement and there is no other equivalent line in the source code. We also use the same debug location for the branch instruction added to jump from artificial entry block for the outlined function, which just jumps to the first actual basic block of the outlined function. Reviewers: davide, aprantl, rriddle, dblaikie, danielcdh, wmi Reviewed By: aprantl, rriddle, danielcdh Subscribers: eraman, JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D40413 llvm-svn: 320199
* [CodeExtractor] Add missing AllowVarArgs initialization.Florian Hahn2017-11-131-2/+3
| | | | llvm-svn: 318029
* [PartialInliner] Inline vararg functions that forward varargs.Florian Hahn2017-11-131-15/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch extends the partial inliner to support inlining parts of vararg functions, if the vararg handling is done in the outlined part. It adds a `ForwardVarArgsTo` argument to InlineFunction. If it is non-null, all varargs passed to the inlined function will be added to all calls to `ForwardVarArgsTo`. The partial inliner takes care to only pass `ForwardVarArgsTo` if the varargs handing is done in the outlined function. It checks that vastart is not part of the function to be inlined. `test/Transforms/CodeExtractor/PartialInlineNoInline.ll` (already part of the repo) checks we do not do partial inlining if vastart is used in a basic block that will be inlined. Reviewers: davide, davidxl, grosser Reviewed By: davide, davidxl, grosser Subscribers: gyiu, grosser, eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D39607 llvm-svn: 318028
* [CodeExtractor] Fix iterator invalidation in findOrCreateBlockForHoisting.Florian Hahn2017-11-011-1/+3
| | | | | | | | | | | | | | | | | | | Summary: By replacing branches to CommonExitBlock, we remove the node from CommonExitBlock's predecessors, invalidating the iterator. The problem is exposed when the common exit block has multiple predecessors and needs to sink lifetime info. The modification in the test case trigger the issue. Reviewers: davidxl, davide, wmi Reviewed By: davidxl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D39112 llvm-svn: 317084
* [Transforms] Fix some Clang-tidy modernize and Include What You Use ↵Eugene Zelenko2017-10-111-26/+42
| | | | | | warnings; other minor fixes (NFC). llvm-svn: 315516
* [CodeExtractor] Fix multiple bugs under certain shape of extracted regionJakub Kuderski2017-10-061-77/+31
| | | | | | | | | | | | | | | | Summary: If the extracted region has multiple exported data flows toward the same BB which is not included in the region, correct resotre instructions and PHI nodes won't be generated inside the exitStub. The solution is simply put the restore instructions right after the definition of output values instead of putting in exitStub. Unittest for this bug is included. Author: myhsu Reviewers: chandlerc, davide, lattner, silvas, davidxl, wmi, kuhar Subscribers: dberlin, kuhar, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D37902 llvm-svn: 315041
* [CodeExtractor] Remove unneded and commented out debugging stmts.Davide Italiano2017-07-021-6/+0
| | | | llvm-svn: 306966
* [CodeExtractor] Prevent extraction of block involving blockaddressSerge Guelton2017-06-271-0/+27
| | | | | | | | | BlockAddress are only valid within their function context, which does not interact well with CodeExtractor. Detect this case and prevent it. Differential Revision: https://reviews.llvm.org/D33839 llvm-svn: 306448
* [PartialInlining] Support shrinkwrap life_range markersXinliang David Li2017-06-111-16/+203
| | | | | | Differential Revision: http://reviews.llvm.org/D33847 llvm-svn: 305170
* [PartialInlining] Shrinkwrap allocas with live range contained in outline ↵Xinliang David Li2017-05-301-7/+76
| | | | | | | | region. Differential Revision: http://reviews.llvm.org/D33618 llvm-svn: 304245
* [CodeExtractor]: Fixup use refs of the old phi.Xinliang David Li2017-04-251-0/+1
| | | | | | Differential Revision: http://reviews.llvm.org/D32468 llvm-svn: 301291
* [PartialInliner] Fix crash when inlining functions with unreachable blocks.Davide Italiano2017-04-211-12/+13
| | | | | | | | | | | | | | | | CodeExtractor looks up the dominator node corresponding to return blocks when splitting them. If one of these blocks is unreachable, there's no node in the Dom and CodeExtractor crashes because it doesn't check for domtree node validity. In theory, we could add just a check for skipping null DTNodes in `splitReturnBlock` but the fix I propose here is slightly different. To the best of my knowledge, unreachable blocks are irrelevant for the algorithm, therefore we can just skip them when building the candidate set in the constructor. Differential Revision: https://reviews.llvm.org/D32335 llvm-svn: 300946
* [CodeExtractor] Remove an unneeded level of indirection. NFCI.Davide Italiano2017-04-211-11/+6
| | | | llvm-svn: 300931
* Use basicblock split block utility functionXinliang David Li2017-04-201-8/+2
| | | | | | | | | Instead of calling BasicBlock::SplitBasicBlock directly in CodeExtractor. Differential Revision: https://reviews.llvm.org/D32308 llvm-svn: 300899
* [CodeExtractor] Remove a bunch of unneeded constructors.Davide Italiano2017-04-201-24/+0
| | | | | | Differential Revision: https://reviews.llvm.org/D32305 llvm-svn: 300869
* Reland "[IR] Make AttributeSetNode public, avoid temporary AttributeList copies"Reid Kleckner2017-04-101-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | This re-lands r299875. I introduced a bug in Clang code responsible for replacing K&R, no prototype declarations with a real function definition with a prototype. The bug was here: // Collect any return attributes from the call. - if (oldAttrs.hasAttributes(llvm::AttributeList::ReturnIndex)) - newAttrs.push_back(llvm::AttributeList::get(newFn->getContext(), - oldAttrs.getRetAttributes())); + newAttrs.push_back(oldAttrs.getRetAttributes()); Previously getRetAttributes() carried AttributeList::ReturnIndex in its AttributeList. Now that we return the AttributeSetNode* directly, it no longer carries that index, and we call this overload with a single node: AttributeList::get(LLVMContext&, ArrayRef<AttributeSetNode*>) That aborted with an assertion on x86_32 targets. I added an explicit triple to the test and added CHECKs to help find issues like this in the future sooner. llvm-svn: 299899
* Allow DataLayout to specify addrspace for allocas.Matt Arsenault2017-04-101-5/+9
| | | | | | | | | | | | | | | | | | | | | | | LLVM makes several assumptions about address space 0. However, alloca is presently constrained to always return this address space. There's no real way to avoid using alloca, so without this there is no way to opt out of these assumptions. The problematic assumptions include: - That the pointer size used for the stack is the same size as the code size pointer, which is also the maximum sized pointer. - That 0 is an invalid, non-dereferencable pointer value. These are problems for AMDGPU because alloca is used to implement the private address space, which uses a 32-bit index as the pointer value. Other pointers are 64-bit and behave more like LLVM's notion of generic address space. By changing the address space used for allocas, we can change our generic pointer type to be LLVM's generic pointer type which does have similar properties. llvm-svn: 299888
* Revert "[IR] Make AttributeSetNode public, avoid temporary AttributeList copies"Reid Kleckner2017-04-101-1/+2
| | | | | | | This reverts r299875. A Linux bot came back with a test failure: http://bb.pgr.jp/builders/test-clang-i686-linux-RA/builds/741/steps/test_clang/logs/Clang%20%3A%3A%20CodeGen__2006-05-19-SingleEltReturn.c llvm-svn: 299878
* [IR] Make AttributeSetNode public, avoid temporary AttributeList copiesReid Kleckner2017-04-101-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: AttributeList::get(Fn|Ret|Param)Attributes no longer creates a temporary AttributeList just to hide the AttributeSetNode type. I've also added a factory method to create AttributeLists from a parallel array of AttributeSetNodes. I think this simplifies construction of AttributeLists when rewriting function prototypes. Previously we would test if a particular index had attributes, and conditionally add a temporary attribute list to a vector. Now the attribute set vector is parallel to the argument vector already that these passes already construct. My long term vision is to wrap AttributeSetNode* inside an AttributeSet type that holds the enum attributes, but that will come in a follow up change. I haven't done any performance measurements for this change because profiling hasn't shown that any of the affected code is hot. Reviewers: pete, chandlerc, sanjoy, hfinkel Reviewed By: pete Subscribers: jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D31198 llvm-svn: 299875
* Rename AttributeSet to AttributeListReid Kleckner2017-03-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
* Use const-ref in range-loop for to avoid copying pairs of std::stringSean Silva2017-02-221-1/+1
| | | | | | | | | | No reason to create temporaries. Differential Revision: https://reviews.llvm.org/D29871 Patch by sergio.martins! llvm-svn: 295807
* CodeExtractor : Add ability to preserve profile data.Sean Silva2016-08-021-16/+110
| | | | | | | | | | | Added ability to estimate the entry count of the extracted function and the branch probabilities of the exit branches. Patch by River Riddle! Differential Revision: https://reviews.llvm.org/D22744 llvm-svn: 277411
* Revert r277313 and r277314.Sean Silva2016-08-011-110/+16
| | | | | | | | | | | | | | | They seem to trigger an LSan failure: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/15140/steps/check-llvm%20asan/logs/stdio Revert "Add the tests for r277313" This reverts commit r277314. Revert "CodeExtractor : Add ability to preserve profile data." This reverts commit r277313. llvm-svn: 277317
* Fix - CodeExtractor : Inherit Target Dependent Attributes from the parent ↵Sean Silva2016-08-011-1/+16
| | | | | | | | | | | | | | | | | | | function. When extracting a set of blocks make sure to inherit all of the target dependent attributes to make sure that the function will be valid for lowering. One example is the "target-features" attribute for x86, if the extracted region has functionality that relies on a specific feature it will fail to be lowered. This also allows for extracted functions to be valid for inlining, at least back into the parent function, as the target attributes are tested when inlining for compatibility. Patch by River Riddle! Differential Revision: https://reviews.llvm.org/D22713 llvm-svn: 277315
* CodeExtractor : Add ability to preserve profile data.Sean Silva2016-08-011-16/+110
| | | | | | | | | | | Added ability to estimate the entry count of the extracted function and the branch probabilities of the exit branches. Patch by River Riddle! Differential Revision: https://reviews.llvm.org/D22744 llvm-svn: 277313
* Refactor - CodeExtractor : Move check for valid block to static utilitySean Silva2016-07-271-2/+2
| | | | | | | | | | | This lets you actually check to see if a block is valid before trying to extract. Patch by River Riddle! Differential Revision: https://reviews.llvm.org/D22699 llvm-svn: 276846
OpenPOWER on IntegriCloud