summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
...
* Silence static analyzer getAs<VectorType> null dereference warnings. NFCI.Simon Pilgrim2019-10-022-4/+4
| | | | | | The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<VectorType> directly and if not assert will fire for us. llvm-svn: 373478
* Log2_32 returns an unsigned. NFCI.Simon Pilgrim2019-10-021-1/+2
| | | | | | Silences clang static analyzer warning about out of bounds (negative) shifts. llvm-svn: 373451
* Rename TypeNodes.def to TypeNodes.inc for consistency across allJohn McCall2019-10-024-6/+6
| | | | | | | | our autogenerated files. NFC. As requested by Nico Weber. llvm-svn: 373425
* Fix unused variable warning. NFCI.Michael Liao2019-10-021-4/+4
| | | | llvm-svn: 373410
* [clang][OpenMP][NFC] #include GlobalDecl.h to avoid incomplete class typeJordan Rupprecht2019-10-011-1/+1
| | | | llvm-svn: 373400
* CGVTables - silence static analyzer getAs<FunctionProtoType> null ↵Simon Pilgrim2019-10-011-3/+2
| | | | | | | | dereference warnings. NFCI. The static analyzer is warning about potential null dereferences, but we should be able to use castAs<FunctionProtoType> directly and if not assert will fire for us. llvm-svn: 373398
* CGExprAgg - remove duplicate code. NFCI.Simon Pilgrim2019-10-011-1/+1
| | | | | | Remove duplicate getAs<> call, avoiding a clang static analyzer null dereference warning. llvm-svn: 373396
* [OPENMP50]Initial codegen for declare variant implementation vendor.Alexey Bataev2019-10-013-0/+150
| | | | | | | Initial implementation of global aliases emission for the declare variant pragma with implementation vendor context selector set. llvm-svn: 373387
* [OPENMP]Fix PR43330: OpenMP target: Mapping of partial arrays fails.Alexey Bataev2019-10-011-8/+27
| | | | | | Fixed calculation the size of the array sections. llvm-svn: 373374
* Don't elide the use of the thread wrapper for a thread_local constinitRichard Smith2019-10-011-2/+3
| | | | | | | | | variable with non-trivial destruction. We still need to invoke the thread wrapper to trigger registration of the destructor call on thread shutdown. llvm-svn: 373289
* [Clang] Use -main-file-name for source filename if not setTeresa Johnson2019-09-301-2/+10
| | | | | | | | | | | | | | | | | | | -main-file-name is currently used to set the source name used in debug information. If the source filename is "-" and -main-file-name is set, then use the filename also for source_filename and ModuleID of the output. The argument is generally used outside the internal clang calls when running clang in a wrapper like icecc which gives the source via stdin but still wants to get a object file with the original source filename both in debug info and IR code. Patch by: the_jk (Joel Klinghed) Differential Revision: https://reviews.llvm.org/D67592 llvm-svn: 373217
* [Alignment][NFC] Remove AllocaInst::setAlignment(unsigned)Guillaume Chatelet2019-09-304-5/+5
| | | | | | | | | | | | | | | | | Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: jholewinski, arsenm, jvesely, nhaehnle, eraman, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D68141 llvm-svn: 373207
* [Alignment][NFC] Remove LoadInst::setAlignment(unsigned)Guillaume Chatelet2019-09-301-1/+1
| | | | | | | | | | | | | | | | | Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet, jdoerfert Subscribers: hiraditya, asbirlea, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D68142 llvm-svn: 373195
* For P0784R7: compute whether a variable has constant destruction if itRichard Smith2019-09-296-23/+13
| | | | | | | | | | has a constexpr destructor. For constexpr variables, reject if the variable does not have constant destruction. In all cases, do not emit runtime calls to the destructor for variables with constant destruction. llvm-svn: 373159
* [TimeProfiler] Fix "OptModule" section and add new "Backend" sectionsAnton Afanasyev2019-09-281-0/+3
| | | | | | | Remove unnecessary "OptModule" section. Add "PerFunctionPasses", "PerModulePasses" and "CodeGenPasses" sections under "Backend" section. llvm-svn: 373142
* [Clang][OpenMP Offload] Create start/end symbols for the offloading entry ↵Sergey Dmitriev2019-09-271-9/+8
| | | | | | | | | | | | table with a help of a linker Linker automatically provides __start_<section name> and __stop_<section name> symbols to satisfy unresolved references if <section name> is representable as a C identifier (see https://sourceware.org/binutils/docs/ld/Input-Section-Example.html for details). These symbols indicate the start address and end address of the output section respectively. Therefore, renaming OpenMP offload entries section name from ".omp.offloading_entries" to "omp_offloading_entries" to use this feature. This is the first part of the patch for eliminating OpenMP linker script (please see https://reviews.llvm.org/D64943). Differential Revision: https://reviews.llvm.org/D68070 llvm-svn: 373118
* [HIP] Support new kernel launching APIYaxun Liu2019-09-241-6/+11
| | | | | | Differential Revision: https://reviews.llvm.org/D67947 llvm-svn: 372773
* Support for DWARF-5 C++ language tags.Adrian Prantl2019-09-242-1/+9
| | | | | | | | | | | | This patch provides support for DW_LANG_C_plus_plus_11, DW_LANG_C_plus_plus_14 tags in the Clang C++ frontend. Patch by Sourabh Singh Tomar! Differential Revision: https://reviews.llvm.org/D67613 Reapplies r372663 after adapting a failing test in the LLDB testsuite. llvm-svn: 372681
* Revert "Support for DWARF-5 C++ language tags."Jonas Devlieghere2019-09-232-9/+1
| | | | | | This reverts commit bf9c8ffb54943c6d77398adbedddf05ef9724007. llvm-svn: 372672
* Support for DWARF-5 C++ language tags.Adrian Prantl2019-09-232-1/+9
| | | | | | | | | | This patch provides support for DW_LANG_C_plus_plus_11, DW_LANG_C_plus_plus_14 tags in the Clang C++ frontend. Patch by Sourabh Singh Tomar! Differential Revision: https://reviews.llvm.org/D67613 llvm-svn: 372663
* [OPENMP]Use standard parsing for 'match' clause, NFC.Alexey Bataev2019-09-231-0/+1
| | | | | | | Reused standard clauses parsing scheme for parsing/matching 'match' clause in 'declare variant' directive. llvm-svn: 372635
* [OPENMP]Fix PR43355: DO not emit target calls if only -fopenmp-targetsAlexey Bataev2019-09-231-0/+4
| | | | | | | | | is not provided. We should not emit any target-dependent code if only -fopenmp flag is used and device targets are not provided to prevent compiler crash. llvm-svn: 372623
* [OPENMP]Call __kmpc_push_tripcount in task context.Alexey Bataev2019-09-233-58/+71
| | | | | | | | | Runtime function __kmpc_push_tripcount better to call inside of the task context for target regions. Otherwise, the libomptarget is unable to link the provided tripcount value for nowait target regions and completely looses this information. llvm-svn: 372609
* [Alignment] fix buildGuillaume Chatelet2019-09-231-5/+6
| | | | llvm-svn: 372562
* [OPENMP]Fix for PR43349: Crash for privatized loop bound.Alexey Bataev2019-09-181-0/+16
| | | | | | | | If the variable, used in the loop boundaries, is not captured in the construct, this variable must be considered as undefined if it was privatized. llvm-svn: 372252
* Revert r372082 "[Clang] Pragma vectorize_width() implies vectorize(enable)"Hans Wennborg2019-09-181-8/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This broke the Chromium build. Consider the following code: float ScaleSumSamples_C(const float* src, float* dst, float scale, int width) { float fsum = 0.f; int i; #if defined(__clang__) #pragma clang loop vectorize_width(4) #endif for (i = 0; i < width; ++i) { float v = *src++; fsum += v * v; *dst++ = v * scale; } return fsum; } Compiling at -Oz, Clang now warns: $ clang++ -target x86_64 -Oz -c /tmp/a.cc /tmp/a.cc:1:7: warning: loop not vectorized: the optimizer was unable to perform the requested transformation; the transformation might be disabled or specified as part of an unsupported transformation ordering [-Wpass-failed=transform-warning] this suggests it's not actually enabling vectorization hard enough. At -Os it asserts instead: $ build.release/bin/clang++ -target x86_64 -Os -c /tmp/a.cc clang-10: /work/llvm.monorepo/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:2734: void llvm::InnerLoopVectorizer::emitMemRuntimeChecks(llvm::Loop*, llvm::BasicBlock*): Assertion ` !BB->getParent()->hasOptSize() && "Cannot emit memory checks when optimizing for size"' failed. Of course neither of these are what the developer expected from the pragma. > Specifying the vectorization width was supposed to implicitly enable > vectorization, except that it wasn't really doing this. It was only > setting the vectorize.width metadata, but not vectorize.enable. > > This should fix PR27643. > > Differential Revision: https://reviews.llvm.org/D66290 llvm-svn: 372225
* Add SpellingNotCalculated to Attribute Enums to suppress UBSan warningsErich Keane2019-09-171-0/+2
| | | | | | | UBSan downstreams noticed that the assignment of SpellingNotCalculated to the spellings caused warnings. llvm-svn: 372124
* [Clang] Pragma vectorize_width() implies vectorize(enable)Sjoerd Meijer2019-09-171-0/+8
| | | | | | | | | | | | Specifying the vectorization width was supposed to implicitly enable vectorization, except that it wasn't really doing this. It was only setting the vectorize.width metadata, but not vectorize.enable. This should fix PR27643. Differential Revision: https://reviews.llvm.org/D66290 llvm-svn: 372082
* [WebAssembly] Narrowing and widening SIMD opsThomas Lively2019-09-131-0/+57
| | | | | | | | | | | | | | | | Summary: Implements target-specific LLVM intrinsics and clang builtins for these new SIMD operations, as described at https://github.com/WebAssembly/simd/blob/master/proposals/simd/SIMD.md#integer-to-integer-narrowing. Reviewers: aheejin Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D67425 llvm-svn: 371906
* [OPENMP5.0]Add basic support for declare variant directive.Alexey Bataev2019-09-132-0/+9
| | | | | | | Added basic support for declare variant directive and its match clause with user context selector. llvm-svn: 371892
* [NFCI]Create CommonAttributeInfo Type as base type of *Attr and ParsedAttr.Erich Keane2019-09-131-2/+3
| | | | | | | | | | | | In order to enable future improvements to our attribute diagnostics, this moves info from ParsedAttr into CommonAttributeInfo, then makes this type the base of the *Attr and ParsedAttr types. Quite a bit of refactoring took place, including removing a bunch of redundant Spelling Index propogation. Differential Revision: https://reviews.llvm.org/D67368 llvm-svn: 371875
* Improve code generation for thread_local variables:Richard Smith2019-09-124-14/+79
| | | | | | | | | | | | | | | | | | | | | Summary: * Don't bother using a thread wrapper when the variable is known to have constant initialization. * Emit the thread wrapper as discardable-if-unused in TUs that don't contain a definition of the thread_local variable. * Don't emit the thread wrapper at all if the thread_local variable is unused and discardable; it will be emitted by all TUs that need it. Reviewers: rjmccall, jdoerfert Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67429 llvm-svn: 371767
* [WebAssembly] Add -fwasm-exceptions for wasm EHHeejin Ahn2019-09-122-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This adds `-fwasm-exceptions` (in similar fashion with `-fdwarf-exceptions` or `-fsjlj-exceptions`) that turns on everything with wasm exception handling from the frontend to the backend. We currently have `-mexception-handling` in clang frontend, but this is only about the architecture capability and does not turn on other necessary options such as the exception model in the backend. (This can be turned on with `llc -exception-model=wasm`, but llc is not invoked separately as a command line tool, so this option has to be transferred from clang.) Turning on `-fwasm-exceptions` in clang also turns on `-mexception-handling` if not specified, and will error out if `-mno-exception-handling` is specified. Reviewers: dschuff, tlively, sbc100 Subscribers: aprantl, jgravelle-google, sunfish, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67208 llvm-svn: 371708
* Reland "clang-misexpect: Profile Guided Validation of Performance ↵Petr Hosek2019-09-111-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Annotations in LLVM" This patch contains the basic functionality for reporting potentially incorrect usage of __builtin_expect() by comparing the developer's annotation against a collected PGO profile. A more detailed proposal and discussion appears on the CFE-dev mailing list (http://lists.llvm.org/pipermail/cfe-dev/2019-July/062971.html) and a prototype of the initial frontend changes appear here in D65300 We revised the work in D65300 by moving the misexpect check into the LLVM backend, and adding support for IR and sampling based profiles, in addition to frontend instrumentation. We add new misexpect metadata tags to those instructions directly influenced by the llvm.expect intrinsic (branch, switch, and select) when lowering the intrinsics. The misexpect metadata contains information about the expected target of the intrinsic so that we can check against the correct PGO counter when emitting diagnostics, and the compiler's values for the LikelyBranchWeight and UnlikelyBranchWeight. We use these branch weight values to determine when to emit the diagnostic to the user. A future patch should address the comment at the top of LowerExpectIntrisic.cpp to hoist the LikelyBranchWeight and UnlikelyBranchWeight values into a shared space that can be accessed outside of the LowerExpectIntrinsic pass. Once that is done, the misexpect metadata can be updated to be smaller. In the long term, it is possible to reconstruct portions of the misexpect metadata from the existing profile data. However, we have avoided this to keep the code simple, and because some kind of metadata tag will be required to identify which branch/switch/select instructions are influenced by the use of llvm.expect Patch By: paulkirth Differential Revision: https://reviews.llvm.org/D66324 llvm-svn: 371635
* Revert "clang-misexpect: Profile Guided Validation of Performance ↵Dmitri Gribenko2019-09-111-26/+0
| | | | | | | | | | | | | | | | | | | Annotations in LLVM" This reverts commit r371584. It introduced a dependency from compiler-rt to llvm/include/ADT, which is problematic for multiple reasons. One is that it is a novel dependency edge, which needs cross-compliation machinery for llvm/include/ADT (yes, it is true that right now compiler-rt included only header-only libraries, however, if we allow compiler-rt to depend on anything from ADT, other libraries will eventually get used). Secondly, depending on ADT from compiler-rt exposes ADT symbols from compiler-rt, which would cause ODR violations when Clang is built with the profile library. llvm-svn: 371598
* [CodeGen] Add alias for cpu_dispatch function with IFunc & Fix resolver ↵Fangrui Song2019-09-111-3/+24
| | | | | | | | | | | | | | linkage type Multi-versioned functions defined by cpu_dispatch and implemented with IFunc can not be called outside the translation units where they are defined due to lack of symbols. This patch add function aliases for these functions and thus make them visible outside. Differential Revision: https://reviews.llvm.org/D67058 Patch by Senran Zhang llvm-svn: 371586
* clang-misexpect: Profile Guided Validation of Performance Annotations in LLVMPetr Hosek2019-09-111-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch contains the basic functionality for reporting potentially incorrect usage of __builtin_expect() by comparing the developer's annotation against a collected PGO profile. A more detailed proposal and discussion appears on the CFE-dev mailing list (http://lists.llvm.org/pipermail/cfe-dev/2019-July/062971.html) and a prototype of the initial frontend changes appear here in D65300 We revised the work in D65300 by moving the misexpect check into the LLVM backend, and adding support for IR and sampling based profiles, in addition to frontend instrumentation. We add new misexpect metadata tags to those instructions directly influenced by the llvm.expect intrinsic (branch, switch, and select) when lowering the intrinsics. The misexpect metadata contains information about the expected target of the intrinsic so that we can check against the correct PGO counter when emitting diagnostics, and the compiler's values for the LikelyBranchWeight and UnlikelyBranchWeight. We use these branch weight values to determine when to emit the diagnostic to the user. A future patch should address the comment at the top of LowerExpectIntrisic.cpp to hoist the LikelyBranchWeight and UnlikelyBranchWeight values into a shared space that can be accessed outside of the LowerExpectIntrinsic pass. Once that is done, the misexpect metadata can be updated to be smaller. In the long term, it is possible to reconstruct portions of the misexpect metadata from the existing profile data. However, we have avoided this to keep the code simple, and because some kind of metadata tag will be required to identify which branch/switch/select instructions are influenced by the use of llvm.expect Patch By: paulkirth Differential Revision: https://reviews.llvm.org/D66324 llvm-svn: 371584
* Fix for PR43175: compiler crash when trying to emit noncapturableAlexey Bataev2019-09-101-0/+5
| | | | | | | | | | | | | | constant. If the constexpr variable is partially initialized, the initializer can be emitted as the structure, not as an array, because of some early optimizations. The llvm variable gets the type from this constant and, thus, gets the type which is pointer to struct rather than pointer to an array. We need to convert this type to be truely array, otherwise it may lead to the compiler crash when trying to emit array subscript expression. llvm-svn: 371548
* Revert "clang-misexpect: Profile Guided Validation of Performance ↵Petr Hosek2019-09-101-26/+0
| | | | | | | | Annotations in LLVM" This reverts commit r371484: this broke sanitizer-x86_64-linux-fast bot. llvm-svn: 371488
* clang-misexpect: Profile Guided Validation of Performance Annotations in LLVMPetr Hosek2019-09-101-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch contains the basic functionality for reporting potentially incorrect usage of __builtin_expect() by comparing the developer's annotation against a collected PGO profile. A more detailed proposal and discussion appears on the CFE-dev mailing list (http://lists.llvm.org/pipermail/cfe-dev/2019-July/062971.html) and a prototype of the initial frontend changes appear here in D65300 We revised the work in D65300 by moving the misexpect check into the LLVM backend, and adding support for IR and sampling based profiles, in addition to frontend instrumentation. We add new misexpect metadata tags to those instructions directly influenced by the llvm.expect intrinsic (branch, switch, and select) when lowering the intrinsics. The misexpect metadata contains information about the expected target of the intrinsic so that we can check against the correct PGO counter when emitting diagnostics, and the compiler's values for the LikelyBranchWeight and UnlikelyBranchWeight. We use these branch weight values to determine when to emit the diagnostic to the user. A future patch should address the comment at the top of LowerExpectIntrisic.cpp to hoist the LikelyBranchWeight and UnlikelyBranchWeight values into a shared space that can be accessed outside of the LowerExpectIntrinsic pass. Once that is done, the misexpect metadata can be updated to be smaller. In the long term, it is possible to reconstruct portions of the misexpect metadata from the existing profile data. However, we have avoided this to keep the code simple, and because some kind of metadata tag will be required to identify which branch/switch/select instructions are influenced by the use of llvm.expect Patch By: paulkirth Differential Revision: https://reviews.llvm.org/D66324 llvm-svn: 371484
* [NewPM][Sancov] Create the Sancov Pass after building the pipelinesLeonard Chan2019-09-081-17/+7
| | | | | | | | | | | | | | | | | | | | We're running into linker errors from missing sancov sections: ``` ld.lld: error: relocation refers to a discarded section: __sancov_guards >>> defined in user-arm64-ubsan-sancov-full.shlib/obj/third_party/ulib/scudo/scudo.wrappers_c.cc.o >>> referenced by common.h:26 (../../zircon/third_party/ulib/scudo/common.h:26) ... many other references ``` I believe this is due to a pass in the default pipeline that somehow discards these sections. The ModuleSanitizerCoveragePass was initially added at the start of the pipeline. This now adds it to the end of the pipeline for optimized and unoptimized builds. Differential Revision: https://reviews.llvm.org/D67323 llvm-svn: 371326
* Remove stale TLI Module level pass registrationTeresa Johnson2019-09-071-1/+0
| | | | | | | | Clang patch to adapt to LLVM changes in D66428 that make the TLI require a Function. There is no longer a module-level TargetLibraryAnalysis, so remove its registration llvm-svn: 371285
* Use musttail for variadic method thunks when possibleReid Kleckner2019-09-061-11/+41
| | | | | | | | | | | | | | | | | | | | | This avoids cloning variadic virtual methods when the target supports musttail and the return type is not covariant. I think we never implemented this previously because it doesn't handle the covariant case. But, in the MS ABI, there are some cases where vtable thunks must be emitted even when the variadic method defintion is not available, so it looks like we need to implement this. Do it for both ABIs, since it's a nice size improvement and simplification for Itanium. Emit an error when emitting thunks for variadic methods with a covariant return type. This case is essentially not implementable unless the ABI provides a way to perfectly forward variadic arguments without a tail call. Fixes PR43173. Differential Revision: https://reviews.llvm.org/D67028 llvm-svn: 371269
* [NFC][CodeGen][UBSan] EmitCheckedInBoundsGEP(): pass a vector to EmitCheck()Roman Lebedev2019-09-061-2/+6
| | | | | | | | Will be easier to add a new 'check' in a follow-up. This was originally part of https://reviews.llvm.org/D67122 llvm-svn: 371208
* [NFC][CodeGen][UBSan] EmitCheckedInBoundsGEP(): refactor ↵Roman Lebedev2019-09-061-25/+52
| | | | | | | | | | | EmitGEPOffsetInBytes() helper It shouldn't really be inlined into the EmitCheckedInBoundsGEP(). Refactoring it beforehand will make follow-up changes more obvious. This was originally part of https://reviews.llvm.org/D67122 llvm-svn: 371207
* [NFC][CodeGen][UBSan] EmitCheckedInBoundsGEP(): add some comments to ↵Roman Lebedev2019-09-061-8/+18
| | | | | | | | | | pointer-overflow check It's rather eye-twiching, some comments may help here.. This was originally part of https://reviews.llvm.org/D67122 llvm-svn: 371206
* [X86] Prevent passing vectors of __int128 as <X x i128> in llvm IRCraig Topper2019-09-061-2/+40
| | | | | | | | | | | | | As far as I can tell, gcc passes 256/512 bit vectors __int128 in memory. And passes a vector of 1 _int128 in an xmm register. The backend considers <X x i128> as an illegal type and will scalarize any arguments with that type. So we need to coerce the argument types in the frontend to match to avoid the illegal type. I'm restricting this to change to Linux and NetBSD based on the how similar ABI changes have been handled in the past. PS4, FreeBSD, and Darwin are unaffected. I've also added a new -fclang-abi-compat version to restore the old behavior. This issue was identified in PR42607. Though even with the types changed, we still seem to be doing some unnecessary stack realignment. llvm-svn: 371169
* Revert: [DebugInfo] Add debug location to stubs generated by CGDeclCXX and ↵Alexandre Ganea2019-09-052-14/+5
| | | | | | mark them as artificial llvm-svn: 371113
* [DebugInfo] Add debug location to stubs generated by CGDeclCXX and mark them ↵Alexandre Ganea2019-09-052-5/+14
| | | | | | | | as artificial Differential Revision: https://reviews.llvm.org/D66328 llvm-svn: 371080
* Add -m(no)-spe to clangJustin Hibbits2019-09-051-1/+2
| | | | | | | | | | | | | | Summary: r337347 added support for the Signal Processing Engine (SPE) to LLVM. This follows that up with the clang side. This adds -mspe and -mno-spe, to match GCC. Subscribers: nemanjai, kbarton, cfe-commits Differential Revision: https://reviews.llvm.org/D49754 llvm-svn: 371066
OpenPOWER on IntegriCloud