summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/StackProtector.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [CodeGen] stop short-circuiting the SSP code for sspstrong.George Burgess IV2016-09-201-5/+0
| | | | | | | | | | | | | | | | | | This check caused us to skip adding layout information for calls to alloca in sspreq/sspstrong mode. We check properly for sspstrong later on (and add the correct layout info when doing so), so removing this shouldn't hurt. No test is included, since testing this using lit seems to require checking for exact offsets in asm, which is something that the lit tests for this avoid. If someone cares deeply, I'm happy to write a unittest or something to cover this, but that feels like overkill. Patch by Daniel Micay. Differential Revision: https://reviews.llvm.org/D22714 llvm-svn: 282022
* [StackProtector] Use INITIALIZE_TM_PASS instead of INITIALIZE_PASSSilviu Baranga2016-09-141-1/+1
| | | | | | | | | | in order to make sure that its TargetMachine constructor is registered. This allows us to run the PEI machine pass with MIR input (see PR30324). llvm-svn: 281474
* Add an artificial line-0 debug location when the compiler emits a call toYunzhong Gao2016-06-301-0/+2
| | | | | | | | __stack_chk_fail(). This avoids a compiler crash. Differential Revision: http://reviews.llvm.org/D21818 llvm-svn: 274263
* Delete unused includes. NFC.Rafael Espindola2016-06-301-1/+0
| | | | llvm-svn: 274225
* [stack-protection] Add support for MSVC buffer security checkEtienne Bergeron2016-06-071-8/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch is adding support for the MSVC buffer security check implementation The buffer security check is turned on with the '/GS' compiler switch. * https://msdn.microsoft.com/en-us/library/8dbf701c.aspx * To be added to clang here: http://reviews.llvm.org/D20347 Some overview of buffer security check feature and implementation: * https://msdn.microsoft.com/en-us/library/aa290051(VS.71).aspx * http://www.ksyash.com/2011/01/buffer-overflow-protection-3/ * http://blog.osom.info/2012/02/understanding-vs-c-compilers-buffer.html For the following example: ``` int example(int offset, int index) { char buffer[10]; memset(buffer, 0xCC, index); return buffer[index]; } ``` The MSVC compiler is adding these instructions to perform stack integrity check: ``` push ebp mov ebp,esp sub esp,50h [1] mov eax,dword ptr [__security_cookie (01068024h)] [2] xor eax,ebp [3] mov dword ptr [ebp-4],eax push ebx push esi push edi mov eax,dword ptr [index] push eax push 0CCh lea ecx,[buffer] push ecx call _memset (010610B9h) add esp,0Ch mov eax,dword ptr [index] movsx eax,byte ptr buffer[eax] pop edi pop esi pop ebx [4] mov ecx,dword ptr [ebp-4] [5] xor ecx,ebp [6] call @__security_check_cookie@4 (01061276h) mov esp,ebp pop ebp ret ``` The instrumentation above is: * [1] is loading the global security canary, * [3] is storing the local computed ([2]) canary to the guard slot, * [4] is loading the guard slot and ([5]) re-compute the global canary, * [6] is validating the resulting canary with the '__security_check_cookie' and performs error handling. Overview of the current stack-protection implementation: * lib/CodeGen/StackProtector.cpp * There is a default stack-protection implementation applied on intermediate representation. * The target can overload 'getIRStackGuard' method if it has a standard location for the stack protector cookie. * An intrinsic 'Intrinsic::stackprotector' is added to the prologue. It will be expanded by the instruction selection pass (DAG or Fast). * Basic Blocks are added to every instrumented function to receive the code for handling stack guard validation and errors handling. * Guard manipulation and comparison are added directly to the intermediate representation. * lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp * lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp * There is an implementation that adds instrumentation during instruction selection (for better handling of sibbling calls). * see long comment above 'class StackProtectorDescriptor' declaration. * The target needs to override 'getSDagStackGuard' to activate SDAG stack protection generation. (note: getIRStackGuard MUST be nullptr). * 'getSDagStackGuard' returns the appropriate stack guard (security cookie) * The code is generated by 'SelectionDAGBuilder.cpp' and 'SelectionDAGISel.cpp'. * include/llvm/Target/TargetLowering.h * Contains function to retrieve the default Guard 'Value'; should be overriden by each target to select which implementation is used and provide Guard 'Value'. * lib/Target/X86/X86ISelLowering.cpp * Contains the x86 specialisation; Guard 'Value' used by the SelectionDAG algorithm. Function-based Instrumentation: * The MSVC doesn't inline the stack guard comparison in every function. Instead, a call to '__security_check_cookie' is added to the epilogue before every return instructions. * To support function-based instrumentation, this patch is * adding a function to get the function-based check (llvm 'Value', see include/llvm/Target/TargetLowering.h), * If provided, the stack protection instrumentation won't be inlined and a call to that function will be added to the prologue. * modifying (SelectionDAGISel.cpp) do avoid producing basic blocks used for inline instrumentation, * generating the function-based instrumentation during the ISEL pass (SelectionDAGBuilder.cpp), * if FastISEL (not SelectionDAG), using the fallback which rely on the same function-based implemented over intermediate representation (StackProtector.cpp). Modifications * adding support for MSVC (lib/Target/X86/X86ISelLowering.cpp) * adding support function-based instrumentation (lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp, .h) Results * IR generated instrumentation: ``` clang-cl /GS test.cc /Od /c -mllvm -print-isel-input ``` ``` *** Final LLVM Code input to ISel *** ; Function Attrs: nounwind sspstrong define i32 @"\01?example@@YAHHH@Z"(i32 %offset, i32 %index) #0 { entry: %StackGuardSlot = alloca i8* <<<-- Allocated guard slot %0 = call i8* @llvm.stackguard() <<<-- Loading Stack Guard value call void @llvm.stackprotector(i8* %0, i8** %StackGuardSlot) <<<-- Prologue intrinsic call (store to Guard slot) %index.addr = alloca i32, align 4 %offset.addr = alloca i32, align 4 %buffer = alloca [10 x i8], align 1 store i32 %index, i32* %index.addr, align 4 store i32 %offset, i32* %offset.addr, align 4 %arraydecay = getelementptr inbounds [10 x i8], [10 x i8]* %buffer, i32 0, i32 0 %1 = load i32, i32* %index.addr, align 4 call void @llvm.memset.p0i8.i32(i8* %arraydecay, i8 -52, i32 %1, i32 1, i1 false) %2 = load i32, i32* %index.addr, align 4 %arrayidx = getelementptr inbounds [10 x i8], [10 x i8]* %buffer, i32 0, i32 %2 %3 = load i8, i8* %arrayidx, align 1 %conv = sext i8 %3 to i32 %4 = load volatile i8*, i8** %StackGuardSlot <<<-- Loading Guard slot call void @__security_check_cookie(i8* %4) <<<-- Epilogue function-based check ret i32 %conv } ``` * SelectionDAG generated instrumentation: ``` clang-cl /GS test.cc /O1 /c /FA ``` ``` "?example@@YAHHH@Z": # @"\01?example@@YAHHH@Z" # BB#0: # %entry pushl %esi subl $16, %esp movl ___security_cookie, %eax <<<-- Loading Stack Guard value movl 28(%esp), %esi movl %eax, 12(%esp) <<<-- Store to Guard slot leal 2(%esp), %eax pushl %esi pushl $204 pushl %eax calll _memset addl $12, %esp movsbl 2(%esp,%esi), %esi movl 12(%esp), %ecx <<<-- Loading Guard slot calll @__security_check_cookie@4 <<<-- Epilogue function-based check movl %esi, %eax addl $16, %esp popl %esi retl ``` Reviewers: kcc, pcc, eugenis, rnk Subscribers: majnemer, llvm-commits, hans, thakis, rnk Differential Revision: http://reviews.llvm.org/D20346 llvm-svn: 272053
* [SSP, 2/2] Create llvm.stackguard() intrinsic and lower it to LOAD_STACK_GUARDTim Shen2016-04-191-24/+37
| | | | | | | | | | | | | | | | | | | | | | | With this change, ideally IR pass can always generate llvm.stackguard call to get the stack guard; but for now there are still IR form stack guard customizations around (see getIRStackGuard()). Future SSP customization should go through LOAD_STACK_GUARD. There is a behavior change: stack guard values are not CSEed anymore, since we should never reuse the value in case that it has been spilled (and corrupted). See ssp-guard-spill.ll. This also cause the change of stack size and codegen in X86 and AArch64 test cases. Ideally we'd like to know if the guard created in llvm.stackprotector() gets spilled or not. If the value is spilled, discard the value and reload stack guard; otherwise reuse the value. This can be done by teaching register allocator to know how to rematerialize LOAD_STACK_GUARD and force a rematerialization (which seems hard), or check for spilling in expandPostRAPseudo. It only makes sense when the stack guard is a global variable, which requires more instructions to load. Anyway, this seems to go out of the scope of the current patch. llvm-svn: 266806
* [safestack] Add canary to unsafe stack framesEvgeniy Stepanov2016-04-111-0/+3
| | | | | | | | Add StackProtector to SafeStack. This adds limited protection against data corruption in the caller frame. Current implementation treats all stack protector levels as -fstack-protector-all. llvm-svn: 266004
* [SSP] Remove llvm.stackprotectorcheck.Tim Shen2016-04-081-95/+31
| | | | | | | | | | This is a cleanup patch for SSP support in LLVM. There is no functional change. llvm.stackprotectorcheck is not needed, because SelectionDAG isn't actually lowering it in SelectBasicBlock; rather, it adds check code in FinishBasicBlock, ignoring the position where the intrinsic is inserted (See FindSplitPointForStackProtector()). llvm-svn: 265851
* Faster stack-protector for Android/AArch64.Evgeniy Stepanov2016-04-051-16/+12
| | | | | | | Bionic has a defined thread-local location for the stack protector cookie. Emit a direct load instead of going through __stack_chk_guard. llvm-svn: 265481
* [BPI] Replace weights by probabilities in BPI.Cong Hou2015-12-221-5/+6
| | | | | | | | | | | | This patch removes all weight-related interfaces from BPI and replace them by probability versions. With this patch, we won't use edge weight anymore in either IR or MC passes. Edge probabilitiy is a better representation in terms of CFG update and validation. Differential revision: http://reviews.llvm.org/D15519 llvm-svn: 256263
* Refactor: Simplify boolean conditional return statements in lib/CodeGen.Rafael Espindola2015-10-241-4/+1
| | | | | | Patch by Richard. llvm-svn: 251213
* CodeGen: Remove implicit ilist iterator conversions, NFCDuncan P. N. Exon Smith2015-10-091-2/+2
| | | | | | | Finish removing implicit ilist iterator conversions from LLVMCodeGen. I'm sure there are lots more of these in lib/CodeGen/*/. llvm-svn: 249915
* Redirect DataLayout from TargetMachine to Module in StackProtectorMehdi Amini2015-07-071-1/+1
| | | | | | | | | | | | | | | | Summary: This change is part of a series of commits dedicated to have a single DataLayout during compilation by using always the one owned by the module. Reviewers: echristo Subscribers: llvm-commits, rafael, yaron.keren Differential Revision: http://reviews.llvm.org/D11010 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 241646
* Simplify IRBuilder::CreateCall* by using ArrayRef+initializer_list/braced ↵David Blaikie2015-05-181-3/+3
| | | | | | init only llvm-svn: 237624
* CodeGen: Canonicalize access to function attributes, NFCDuncan P. N. Exon Smith2015-02-141-8/+4
| | | | | | | | | | | | | | | | | Canonicalize access to function attributes to use the simpler API. getAttributes().getAttribute(AttributeSet::FunctionIndex, Kind) => getFnAttribute(Kind) getAttributes().hasAttribute(AttributeSet::FunctionIndex, Kind) => hasFnAttribute(Kind) Also, add `Function::getFnStackAlignment()`, and canonicalize: getAttributes().getStackAlignment(AttributeSet::FunctionIndex) => getFnStackAlignment() llvm-svn: 229208
* Replace some uses of getSubtargetImpl with the cached versionEric Christopher2015-01-271-1/+1
| | | | | | | off of the MachineFunction or with the version that takes a Function reference as an argument. llvm-svn: 227185
* CodeGen: minor style tweaks to SSPSaleem Abdulrasool2014-12-211-13/+15
| | | | | | Clean up some style related things in the StackProtector CodeGen. NFC. llvm-svn: 224693
* CodeGen: constify and use range loop for SSPSaleem Abdulrasool2014-12-201-8/+4
| | | | | | Use range-based for loop and constify the iterators. NFC. llvm-svn: 224683
* [stack protector] Set edge weights for newly created basic blocks.Akira Hatanaka2014-12-011-1/+9
| | | | | | | | | This commit fixes a bug in stack protector pass where edge weights were not set when new basic blocks were added to lists of successor basic blocks. Differential Revision: http://reviews.llvm.org/D5766 llvm-svn: 222987
* Target triple OS detection tidyup. NFCSimon Pilgrim2014-11-291-2/+2
| | | | | | Use Triple::isOS*() helpers where possible. llvm-svn: 222960
* Update SetVector to rely on the underlying set's insert to return a ↵David Blaikie2014-11-191-1/+1
| | | | | | | | | | | | | pair<iterator, bool> This is to be consistent with StringSet and ultimately with the standard library's associative container insert function. This lead to updating SmallSet::insert to return pair<iterator, bool>, and then to update SmallPtrSet::insert to return pair<iterator, bool>, and then to update all the existing users of those functions... llvm-svn: 222334
* Use nullptr instead of NULL for variadic sentinelsReid Kleckner2014-11-131-2/+2
| | | | | | | | | | Windows defines NULL to 0, which when used as an argument to a variadic function, is not a null pointer constant. As a result, Clang's -Wsentinel fires on this code. Using '0' would be wrong on most 64-bit platforms, but both MSVC and Clang make it work on Windows. Sidestep the issue with nullptr. llvm-svn: 221940
* Remove the TargetMachine forwards for TargetSubtargetInfo basedEric Christopher2014-08-041-1/+2
| | | | | | information and update all callers. No functional change. llvm-svn: 214781
* [Modules] Remove potential ODR violations by sinking the DEBUG_TYPEChandler Carruth2014-04-221-1/+2
| | | | | | | | | | | | 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. llvm-svn: 206837
* [stack protector] Make the StackProtector pass respect ssp-buffer-size.Josh Magee2014-04-171-3/+3
| | | | | | | | | | | Previously, SSPBufferSize was assigned the value of the "stack-protector-buffer-size" attribute after all uses of SSPBufferSize. The effect was that the default SSPBufferSize was always used during analysis. I moved the check for the attribute before the analysis; now --param ssp-buffer-size= works correctly again. Differential Revision: http://reviews.llvm.org/D3349 llvm-svn: 206486
* [C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper2014-04-141-7/+7
| | | | | | instead of comparing to nullptr. llvm-svn: 206142
* [C++11] Add range based accessors for the Use-Def chain of a Value.Chandler Carruth2014-03-091-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This requires a number of steps. 1) Move value_use_iterator into the Value class as an implementation detail 2) Change it to actually be a *Use* iterator rather than a *User* iterator. 3) Add an adaptor which is a User iterator that always looks through the Use to the User. 4) Wrap these in Value::use_iterator and Value::user_iterator typedefs. 5) Add the range adaptors as Value::uses() and Value::users(). 6) Update *all* of the callers to correctly distinguish between whether they wanted a use_iterator (and to explicitly dig out the User when needed), or a user_iterator which makes the Use itself totally opaque. Because #6 requires churning essentially everything that walked the Use-Def chains, I went ahead and added all of the range adaptors and switched them to range-based loops where appropriate. Also because the renaming requires at least churning every line of code, it didn't make any sense to split these up into multiple commits -- all of which would touch all of the same lies of code. The result is still not quite optimal. The Value::use_iterator is a nice regular iterator, but Value::user_iterator is an iterator over User*s rather than over the User objects themselves. As a consequence, it fits a bit awkwardly into the range-based world and it has the weird extra-dereferencing 'operator->' that so many of our iterators have. I think this could be fixed by providing something which transforms a range of T&s into a range of T*s, but that *can* be separated into another patch, and it isn't yet 100% clear whether this is the right move. However, this change gets us most of the benefit and cleans up a substantial amount of code around Use and User. =] llvm-svn: 203364
* [C++11] Replace llvm::next and llvm::prior with std::next and std::prev.Benjamin Kramer2014-03-021-2/+1
| | | | | | Remove the old functions. llvm-svn: 202636
* Checked return warning from coverityRenato Golin2014-01-211-2/+3
| | | | llvm-svn: 199716
* Update StackProtector when coloring merges stack slotsHal Finkel2014-01-201-0/+21
| | | | | | | | | | | | | | | | StackProtector keeps a ValueMap of alloca instructions to layout kind tags for use by PEI and other later passes. When stack coloring replaces one alloca with a bitcast to another one, the key replacement in this map does not work. Instead, provide an interface to manage this updating directly. This seems like an improvement over the old behavior, where the layout map would not get updated at all when the stack slots were merged. In practice, however, there is likely no observable difference because PEI only did anything special with 'large array' kinds, and if one large array is merged with another, than the replacement should already have been a large array. This is an attempt to unbreak the clang-x86_64-darwin11-RA builder. llvm-svn: 199684
* [PM] Split DominatorTree into a concrete analysis result object whichChandler Carruth2014-01-131-1/+3
| | | | | | | | | | | | | | | | | | | | | | | can be used by both the new pass manager and the old. This removes it from any of the virtual mess of the pass interfaces and lets it derive cleanly from the DominatorTreeBase<> template. In turn, tons of boilerplate interface can be nuked and it turns into a very straightforward extension of the base DominatorTree interface. The old analysis pass is now a simple wrapper. The names and style of this split should match the split between CallGraph and CallGraphWrapperPass. All of the users of DominatorTree have been updated to match using many of the same tricks as with CallGraph. The goal is that the common type remains the resulting DominatorTree rather than the pass. This will make subsequent work toward the new pass manager significantly easier. Also in numerous places things became cleaner because I switched from re-running the pass (!!! mid way through some other passes run!!!) to directly recomputing the domtree. llvm-svn: 199104
* Re-sort all of the includes with ./utils/sort_includes.py so thatChandler Carruth2014-01-071-2/+2
| | | | | | | | | | subsequent changes are easier to review. About to fix some layering issues, and wanted to separate out the necessary churn. Also comment and sink the include of "Windows.h" in three .inc files to match the usage in Memory.inc. llvm-svn: 198685
* [stackprotector] Use analysis from the StackProtector pass for stack layout ↵Josh Magee2013-12-191-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | in PEI a nd LocalStackSlot passes. This changes the MachineFrameInfo API to use the new SSPLayoutKind information produced by the StackProtector pass (instead of a boolean flag) and updates a few pass dependencies (to preserve the SSP analysis). The stack layout follows the same approach used prior to this change - i.e., only LargeArray stack objects will be placed near the canary and everything else will be laid out normally. After this change, structures containing large arrays will also be placed near the canary - a case previously missed by the old implementation. Out of tree targets will need to update their usage of MachineFrameInfo::CreateStackObject to remove the MayNeedSP argument. The next patch will implement the rules for sspstrong and sspreq. The end goal is to support ssp-strong stack layout rules. WIP. Differential Revision: http://llvm-reviews.chandlerc.com/D2158 llvm-svn: 197653
* Reformat code with clang-format.Josh Magee2013-10-301-37/+40
| | | | | | Differential Revision: http://llvm-reviews.chandlerc.com/D2057 llvm-svn: 193672
* [stackprotector] Update the StackProtector pass to perform datalayout analysis.Josh Magee2013-10-291-27/+60
| | | | | | | | | | | | | | | This modifies the pass to classify every SSP-triggering AllocaInst according to an SSPLayoutKind (LargeArray, SmallArray, AddrOf). This analysis is collected by the pass and made available for use, but no other pass uses it yet. The next patch will make use of this analysis in PEI and StackSlot passes. The end goal is to support ssp-strong stack layout rules. WIP. Differential Revision: http://llvm-reviews.chandlerc.com/D1789 llvm-svn: 193653
* [stackprotector] Refactor the StackProtector pass from a single .cpp file ↵Josh Magee2013-09-271-70/+1
| | | | | | | | | | | | | | into StackProtector.h and StackProtector.cpp. No functionality change. Future patches will add analysis which will be used in other passes (PEI, StackSlot). The end goal is to support ssp-strong stack layout rules. WIP. Differential Revision: http://llvm-reviews.chandlerc.com/D1521 llvm-svn: 191570
* [stackprotector] Modernize code with IRBuilderBenjamin Kramer2013-09-091-32/+17
| | | | llvm-svn: 190317
* [stackprotector] Small cleanup.Michael Gottesman2013-08-201-1/+2
| | | | llvm-svn: 188772
* [stackprotector] Small Bit of computation hoisting.Michael Gottesman2013-08-201-5/+5
| | | | llvm-svn: 188771
* [stackprotector] Added significantly longer comment to FindPotentialTailCall ↵Michael Gottesman2013-08-201-1/+6
| | | | | | to make clear its relationship to llvm::isInTailCallPosition. llvm-svn: 188770
* Removed trailing whitespace.Michael Gottesman2013-08-201-18/+18
| | | | llvm-svn: 188769
* [stackprotector] Removed stale TODO.Michael Gottesman2013-08-201-6/+3
| | | | llvm-svn: 188768
* [stackprotector] Added support for emitting the llvm intrinsic stack ↵Michael Gottesman2013-08-201-49/+150
| | | | | | | | protector check. rdar://13935163 llvm-svn: 188766
* [stackprotector] Simplify SP Pass so that we emit different fail basic ↵Michael Gottesman2013-08-091-10/+10
| | | | | | | | | | | | | blocks for each fail condition. This patch decouples the stack protector pass so that we can support stack protector implementations that do not use the IR level generated stack protector fail basic block. No codesize increase is caused by this change since the MI level tail merge pass properly merges together the fail condition blocks (see the updated test). llvm-svn: 188105
* [stackprotector] Refactored ssp prologue creation code into its own helper ↵Michael Gottesman2013-07-221-35/+41
| | | | | | | | | | function. No functionality change. rdar://13935163 llvm-svn: 186868
* Recommit r186217 with testcase fix:Bill Wendling2013-07-221-7/+19
| | | | | | | | | Use the function attributes to pass along the stack protector buffer size. Now that we have robust function attributes, don't use a command line option to specify the stack protecto buffer size. llvm-svn: 186863
* Revert commit r186217 -- this is breaking bots:Chandler Carruth2013-07-131-19/+7
| | | | | | | | | | http://lab.llvm.org:8013/builders/clang-x86_64-darwin11-nobootstrap-RAincremental/builds/4328 Original commit log: Use the function attributes to pass along the stack protector buffer size. llvm-svn: 186234
* Use the function attributes to pass along the stack protector buffer size.Bill Wendling2013-07-121-7/+19
| | | | | | | Now that we have robust function attributes, don't use a command line option to specify the stack protecto buffer size. llvm-svn: 186217
* Access the TargetLoweringInfo from the TargetMachine object instead of ↵Bill Wendling2013-06-191-7/+9
| | | | | | caching it. The TLI may change between functions. No functionality change. llvm-svn: 184349
* Support OpenBSD's native frame protection conventions.Rafael Espindola2013-06-071-11/+36
| | | | | | | | | | | | | | | OpenBSD's stack smashing protection differs slightly from other platforms: 1. The smash handler function is "__stack_smash_handler(const char *funcname)" instead of "__stack_chk_fail(void)". 2. There's a hidden "long __guard_local" object that gets linked into each executable and DSO. Patch by Matthew Dempsky. llvm-svn: 183533
OpenPOWER on IntegriCloud