summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* [DebugInfo] Add a DW_OP_LLVM_entry_value operationDavid Stenberg2019-10-1523-51/+322
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Internally in LLVM's metadata we use DW_OP_entry_value operations with the same semantics as DWARF; that is, its operand specifies the number of bytes that the entry value covers. At the time of emitting entry values we don't know the emitted size of the DWARF expression that the entry value will cover. Currently the size is hardcoded to 1 in DIExpression, and other values causes the verifier to fail. As the size is 1, that effectively means that we can only have valid entry values for registers that can be encoded in one byte, which are the registers with DWARF numbers 0 to 31 (as they can be encoded as single-byte DW_OP_reg0..DW_OP_reg31 rather than a multi-byte DW_OP_regx). It is a bit confusing, but it seems like llvm-dwarfdump will print an operation "correctly", even if the byte size is less than that, which may make it seem that we emit correct DWARF for registers with DWARF numbers > 31. If you instead use readelf for such cases, it will interpret the number of specified bytes as a DWARF expression. This seems like a limitation in llvm-dwarfdump. As suggested in D66746, a way forward would be to add an internal variant of DW_OP_entry_value, DW_OP_LLVM_entry_value, whose operand instead specifies the number of operations that the entry value covers, and we then translate that into the byte size at the time of emission. In this patch that internal operation is added. This patch keeps the limitation that a entry value can only be applied to simple register locations, but it will fix the issue with the size operand being incorrect for DWARF numbers > 31. Reviewers: aprantl, vsk, djtodoro, NikolaPrica Reviewed By: aprantl Subscribers: jyknight, fedor.sergeev, hiraditya, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D67492 llvm-svn: 374881
* [Alignment][NFC] Remove dependency on GlobalObject::setAlignment(unsigned)Guillaume Chatelet2019-10-1533-86/+96
| | | | | | | | | | | | | | | | | 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: arsenm, mehdi_amini, jvesely, nhaehnle, hiraditya, steven_wu, dexonsmith, dang, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68944 llvm-svn: 374880
* [DebugInfo] Add interface for pre-calculating the size of emitted DWARFDavid Stenberg2019-10-155-27/+130
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: DWARF's DW_OP_entry_value operation has two operands; the first is a ULEB128 operand that specifies the size of the second operand, which is a DWARF block. This means that we need to be able to pre-calculate and emit the size of DWARF expressions before emitting them. There is currently no interface for doing this in DwarfExpression, so this patch introduces that. When implementing this I initially thought about running through DwarfExpression's emission two times; first with a temporary buffer to emit the expression, in order to being able to calculate the size of that emitted data. However, DwarfExpression is a quite complex state machine, so I decided against that, as it seemed like the two runs could get out of sync, resulting in incorrect size operands. Therefore I have implemented this in a way that we only have to run DwarfExpression once. The idea is to emit DWARF to a temporary buffer, for which it is possible to query the size. The data in the temporary buffer can then be emitted to DwarfExpression's main output. In the case of DIEDwarfExpression, a temporary DIE is used. The values are all allocated using the same BumpPtrAllocator as for all other DIEs, and the values are then transferred to the real value list. In the case of DebugLocDwarfExpression, the temporary buffer is implemented using a BufferByteStreamer which emits to a buffer in the DwarfExpression object. Reviewers: aprantl, vsk, NikolaPrica, djtodoro Reviewed By: aprantl Subscribers: hiraditya, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D67768 llvm-svn: 374879
* [X86] Resolve KnownUndef/KnownZero bits into target shuffle masks in helper. ↵Simon Pilgrim2019-10-151-9/+18
| | | | | | NFCI. llvm-svn: 374878
* [DebugInfo] Remove some users of DBG_VALUEs IsIndirect fieldJeremy Morse2019-10-1522-91/+115
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch kills off a significant user of the "IsIndirect" field of DBG_VALUE machine insts. Brought up in in PR41675, IsIndirect is techncally redundant as it can be expressed by the DIExpression of a DBG_VALUE inst, and it isn't helpful to have two ways of expressing things. Rather than setting IsIndirect, have DBG_VALUE creators add an extra deref to the insts DIExpression. There should now be no appearences of IsIndirect=True from isel down to LiveDebugVariables / VirtRegRewriter, which is ensured by an assertion in LDVImpl::handleDebugValue. This means we also get to delete the IsIndirect handling in LiveDebugVariables. Tests can be upgraded by for example swapping the following IsIndirect=True DBG_VALUE: DBG_VALUE $somereg, 0, !123, !DIExpression(DW_OP_foo) With one where the indirection is in the DIExpression, by _appending_ a deref: DBG_VALUE $somereg, $noreg, !123, !DIExpression(DW_OP_foo, DW_OP_deref) Which both mean the same thing. Most of the test changes in this patch are updates of that form; also some changes in how the textual assembly printer handles these insts. Differential Revision: https://reviews.llvm.org/D68945 llvm-svn: 374877
* Fix uninitialized variable warnings. NFCI.Simon Pilgrim2019-10-151-2/+2
| | | | llvm-svn: 374876
* [llvm-locstats] Fix 'only params' no entry value statsDjordje Todorovic2019-10-151-0/+1
| | | | | | Adding the missing line. llvm-svn: 374875
* [LLD] [COFF] Update a leftover comment after SVN r374869. NFC.Martin Storsjo2019-10-151-1/+1
| | | | llvm-svn: 374874
* [LLD] [COFF] Fix -Wmissing-field-initializers warnings. NFC.Martin Storsjo2019-10-151-1/+1
| | | | llvm-svn: 374873
* [MIPS GlobalISel] Add MSA registers to fprb. Select vector load, storePetar Avramovic2019-10-158-26/+633
| | | | | | | | | | | | | | | | | | Add vector MSA register classes to fprb, they are 128 bit wide. MSA instructions use the same registers for both integer and floating point operations. Therefore we only need to check for vector element size during legalization or instruction selection. Add helper function in MipsLegalizerInfo and switch to legalIf LegalizeRuleSet to keep legalization rules compact since they depend on MipsSubtarget and presence of MSA. fprb is assigned to all vector operands. Move selectLoadStoreOpCode to MipsInstructionSelector in order to reduce number of arguments. Differential Revision: https://reviews.llvm.org/D68867 llvm-svn: 374872
* Change Comments SmallVector to std::vector in DebugLocStream [NFC]David Stenberg2019-10-152-3/+3
| | | | | | | | | | | | | | This changes the 32-element SmallVector to a std::vector. When building a RelWithDebInfo clang-8 binary, the average size of the vector was ~10000, so it does not seem very beneficial or practical to use a small vector for that. The DWARFBytes SmallVector grows in the same way as Comments, so perhaps that also should be changed to a purely dynamically allocated structure, but that requires some more code changes, so I let that remain as a SmallVector for now. llvm-svn: 374871
* [MIPS GlobalISel] Refactor MipsRegisterBankInfo [NFC]Petar Avramovic2019-10-152-153/+127
| | | | | | | | | | Check if size of operand LLT matches sizes of available register banks before inspecting the opcode in order to reduce number of checks. Factor commonly used pieces of code into functions. Differential Revision: https://reviews.llvm.org/D68866 llvm-svn: 374870
* [LLD] [COFF] Wrap file location pair<StringRef,int> in Optional<>. NFC.Martin Storsjo2019-10-153-22/+26
| | | | | | | | | This makes use of it slightly clearer, and makes it match the same construct in the lld ELF linker. Differential Revision: https://reviews.llvm.org/D68935 llvm-svn: 374869
* tsan: fix Go ppc64le buildDmitry Vyukov2019-10-151-0/+2
| | | | | | | | This #define is in the non-Go ppc64le build but not in the Go build. Reviewed-in: https://reviews.llvm.org/D68046 Author: randall77 (Keith Randall) llvm-svn: 374868
* [LLDB] [PECOFF] Use a "pc" vendor name in aarch64 triplesMartin Storsjo2019-10-152-2/+2
| | | | | | | | | | | | | | | | | | | This matches all other architectures listed in the same file. This fixes debugging aarch64 executables with lldb-server, which otherwise fails, with log messages like these: Target::SetArchitecture changing architecture to aarch64 (aarch64-pc-windows-msvc) Target::SetArchitecture Trying to select executable file architecture aarch64 (aarch64-pc-windows-msvc) ArchSpec::SetArchitecture sets the vendor to llvm::Triple::PC for any coff/win32 combination, and if this doesn't match the triple set by the PECOFF module, things doesn't seem to work with when using lldb-server. Differential Revision: https://reviews.llvm.org/D68939 llvm-svn: 374867
* [LLDB] [Windows] Initial support for ARM64 register contextsMartin Storsjo2019-10-1511-3/+1449
| | | | | | Differential Revision: https://reviews.llvm.org/D67954 llvm-svn: 374866
* [Demangle] Add a few more options to the microsoft demanglerMartin Storsjo2019-10-156-21/+86
| | | | | | | | | | | | | | | This corresponds to commonly used options to UnDecorateSymbolName within llvm. Add them as hidden options in llvm-undname. MS undname.exe takes numeric flags, corresponding to the UNDNAME_* constants, but instead of hardcoding in mappings for those numbers, just add textual options instead, as it the use of them here is primarily intended for testing. Differential Revision: https://reviews.llvm.org/D68917 llvm-svn: 374865
* [Format] Add machine-readable SPDX license ID to clang-format.elSam McCall2019-10-151-0/+1
| | | | llvm-svn: 374864
* Fix TestDisassemble_VST1_64Pavel Labath2019-10-151-7/+7
| | | | | | | | - use a full triple instead of just the architecture (makes the test pass on non-apple hosts) - skip the test if the ARM llvm target is not built llvm-svn: 374863
* [X86] Don't check for VBROADCAST_LOAD being a user of the source of a ↵Craig Topper2019-10-151-3/+1
| | | | | | | | | | | | | | | | | | VBROADCAST when trying to share broadcasts. The only things VBROADCAST_LOAD uses is an address and a chain node. It has no vector inputs. So if its a user of the source of another broadcast that could only mean one of two things. The other broadcast is broadcasting the address of the broadcast_load. Or the source is a load and the use we're seeing is the chain result from that load. Neither of these cases make sense to combine here. This issue was reported post-commit r373871. Test case has not been reduced yet. llvm-svn: 374862
* Revert [SROA] Reuse existing lifetime markers if possibleDavid L. Jones2019-10-152-77/+2
| | | | | | | | This reverts r374692 (git commit 92694eba933ef4ea0b1b6377809ff266df37d61b) Reproducer sent to commit thread on llvm-commits. llvm-svn: 374859
* [RISCV] Support fast calling conventionShiva Chen2019-10-153-2/+223
| | | | | | | | | | | | LLVM may annotate the function with fastcc if there has only one caller and there're no other caller out of the module and the function is not naked or contain variable arguments. The fastcc functions could pass the arguments by the caller saved registers. Differential Revision: https://reviews.llvm.org/D68559 llvm-svn: 374857
* [WebAssembly] Trapping fptoint builtins and intrinsicsThomas Lively2019-10-156-0/+186
| | | | | | | | | | | | | | | | | | | | | Summary: The WebAssembly backend lowers fptoint instructions to a code sequence that checks for overflow to avoid traps because fptoint is supposed to be speculatable. These new builtins and intrinsics give users a way to depend on the trapping semantics of the underlying instructions and avoid the extra code generated normally. Patch by coffee and tlively. Reviewers: aheejin Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D68902 llvm-svn: 374856
* [libc++][test] Use <version> to get config on MSVCCasey Carter2019-10-153-6/+6
| | | | | | | | ...instead of `<ciso646>`. Also includes some NFC comment changes. llvm-svn: 374854
* [lldb-server/android] Show more processes by relaxing some checksWalter Erquinigo2019-10-151-34/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | By default `platform process list` only shows the processes of the current user that lldb-server can parse. There are several problems: - apk programs don't have an executable file. They instead use a package name as identifier. We should show them instead. - each apk also runs under a different user. That's how android works - because of the user permission, some files like /proc/<pid>/{environ,exe} can't be read. This results in a very small process list. This is a local run on my machine ``` (lldb) platform process list 2 matching processes were found on "remote-android" PID PARENT USER TRIPLE NAME ====== ====== ========== ======================== ============================ 23291 3177 aarch64-unknown-linux-android sh 23301 23291 aarch64-unknown-linux-android lldb-server ``` However, I have 700 processes running at this time. By implementing a few fallbacks for android, I've expanded this list to 202, filtering out kernel processes, which would presumably appear in this list if the device was rooted. ``` (lldb) platform process list 202 matching processes were found on "remote-android" PID PARENT USER TRIPLE NAME ====== ====== ========== ======================== ============================ ... 12647 3208 aarch64-unknown-linux-android sh 12649 12647 aarch64-unknown-linux-android lldb-server 12653 982 com.samsung.faceservice 13185 982 com.samsung.vvm 15899 982 com.samsung.android.spay 16220 982 com.sec.spp.push 17126 982 com.sec.spp.push:RemoteDlcProcess 19772 983 com.android.chrome 20209 982 com.samsung.cmh:CMH 20380 982 com.google.android.inputmethod.latin 20879 982 com.samsung.android.oneconnect:Receiver 21212 983 com.tencent.mm 24459 1 aarch64-unknown-linux-android wpa_supplicant 25974 982 com.samsung.android.contacts 26293 982 com.samsung.android.messaging 28714 982 com.samsung.android.dialer 31605 982 com.samsung.android.MtpApplication 32256 982 com.bezobidny ``` Something to notice is that the architecture is unkonwn for all apks. And that's fine, because run-as would be required to gather this information and that would make this entire functionality massively slow. There are still several improvements to make here, like displaying actual user names, which I'll try to do in a following diff. Note: Regarding overall apk debugging support from lldb. I'm planning on having lldb spawn lldb-server by itself with the correct user, so that everything works well. The initial lldb-server used for connecting to the remote platform can be reused for such purpose. Furthermore, eventually lldb could also launch that initial lldb-server on its own. Differential Revision: D68289 llvm-svn: 374853
* Revert "fix"Walter Erquinigo2019-10-141-45/+34
| | | | | | This reverts commit d8af64c9a0228301f6fd0e1c841e4abe0b6f4801. llvm-svn: 374852
* Revert [InstCombine] fold a shifted bool zext to a selectSanjay Patel2019-10-143-10/+8
| | | | | | This reverts r374828 (git commit 1f40f15d54aac06421448b6de131231d2d78bc75) due to bot breakage llvm-svn: 374851
* [MemorySSA] Update for partial unswitch.Alina Sbirlea2019-10-1411-0/+135
| | | | | | | | Update MSSA for blocks cloned when doing partial unswitching. Enable additional testing with MSSA. Resolves PR43641. llvm-svn: 374850
* [X86] Teach X86MCodeEmitter to properly encode zmm16-zmm31 as index register ↵Craig Topper2019-10-142-10/+13
| | | | | | | | | | | | to vgatherpf/vscatterpf. We need to encode bit 4 into the EVEX.V' bit. We do this right for regular gather/scatter which use either MRMSrcMem or MRMDestMem formats. The prefetches use MRM*m formats. Fixes an issue recently added to PR36202. llvm-svn: 374849
* [X86] Add encoding tests for avx512pf vgatherpf/vscatterpf instructions.Craig Topper2019-10-141-0/+65
| | | | llvm-svn: 374848
* [lit] Add argument check: --timeout must be non-negative integerJulian Lettner2019-10-141-7/+13
| | | | llvm-svn: 374847
* fixWalter Erquinigo2019-10-141-34/+45
| | | | llvm-svn: 374846
* Revert "Dead Virtual Function Elimination"Jorge Gorbe Moya2019-10-1434-1428/+83
| | | | | | This reverts commit 9f6a873268e1ad9855873d9d8007086c0d01cf4f. llvm-svn: 374844
* Temporarily Revert [Modules][PCH] Hash input files contentEric Christopher2019-10-1412-247/+29
| | | | | | | | as it's breaking a few bots. This reverts r374841 (git commit 2a1386c81de504b5bda44fbecf3f7b4cdfd748fc) llvm-svn: 374842
* [Modules][PCH] Hash input files contentBruno Cardoso Lopes2019-10-1412-29/+247
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When files often get touched during builds, the mtime based validation leads to different problems in implicit modules builds, even when the content doesn't actually change: - Modules only: module invalidation due to out of date files. Usually causing rebuild traffic. - Modules + PCH: build failures because clang cannot rebuild a module if it comes from building a PCH. - PCH: build failures because clang cannot rebuild a PCH in case one of the input headers has different mtime. This patch proposes hashing the content of input files (headers and module maps), which is performed during serialization time. When looking at input files for validation, clang only computes the hash in case there's a mtime mismatch. I've tested a couple of different hash algorithms availble in LLVM in face of building modules+pch for `#import <Cocoa/Cocoa.h>`: - `hash_code`: performace diff within the noise, total module cache increased by 0.07%. - `SHA1`: 5% slowdown. Haven't done real size measurements, but it'd be BLOCK_ID+20 bytes per input file, instead of BLOCK_ID+8 bytes from `hash_code`. - `MD5`: 3% slowdown. Like above, but BLOCK_ID+16 bytes per input file. Given the numbers above, the patch uses `hash_code`. The patch also improves invalidation error msgs to point out which type of problem the user is facing: "mtime", "size" or "content". rdar://problem/29320105 Reviewers: dexonsmith, arphaman, rsmith, aprantl Subscribers: jkorous, cfe-commits, ributzka Tags: #clang Differential Revision: https://reviews.llvm.org/D67249 llvm-svn: 374841
* Add -fno-experimental-pass-manager to make clear which pass managerEric Christopher2019-10-141-1/+1
| | | | | | we're running and to make flipping the default not regress testing. llvm-svn: 374840
* In the new pass manager use PTO.LoopUnrolling to determine when and howEric Christopher2019-10-142-6/+18
| | | | | | | | | | | | | | | | | | | we will unroll loops. Also comment a few occasions where we need to know whether or not we're forcing the unwinder or not. The default before and after this patch is for LoopUnroll to be enabled, and for it to use a cost model to determine whether to unroll the loop (`OnlyWhenForced = false`). Before this patch, disabling loop unroll would not run the LoopUnroll pass. After this patch, the LoopUnroll pass is being run, but it restricts unrolling to only the loops marked by a pragma (`OnlyWhenForced = true`). In addition, this patch disables the UnrollAndJam pass when disabling unrolling. Testcase is in clang because it's controlling how the loop optimizer is being set up and there's no other way to trigger the behavior. llvm-svn: 374838
* [clang] add requirements to -Wa,-W test cases.Jian Cai2019-10-141-0/+3
| | | | | | Include linux as a test requirement. llvm-svn: 374837
* [test] Fix test failureEli Friedman2019-10-141-8/+6
| | | | | | | | | | | | | | The version mismatch symbol is version 9 on 32 bit android. Since this test isn't actually testing any android specific functionality, we force the target triple to x86_64-unknown-unknown in order to have a consistent version number. It seems the test was already trying to do this, just not doing it right Patch by Christopher Tetrault Differential Revision: https://reviews.llvm.org/D68882 llvm-svn: 374836
* [Tests] Add a SCEV analysis test for llvm.widenable.conditionPhilip Reames2019-10-141-0/+45
| | | | | | Mostly because we don't appear to have one and a prototype patch I just saw would have broken the example committed. llvm-svn: 374835
* Add support to -Wa,-W in clangJian Cai2019-10-142-1/+15
| | | | | | | | | | | | | | | | | | | | Summary: Currently clang does not support -Wa,-W, which suppresses warning messages in GNU assembler. Add this option for gcc compatibility. https://bugs.llvm.org/show_bug.cgi?id=43651. Reland with differential information. Reviewers: bcain Reviewed By: bcain Subscribers: george.burgess.iv, gbiv, llozano, manojgupta, nickdesaulniers, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68884 llvm-svn: 374834
* Revert "Add support to -Wa,-W in clang"Jian Cai2019-10-142-15/+1
| | | | | | This reverts commit e72eeca43b9577be2aae55f7603febbf223a6ab3. llvm-svn: 374833
* [ARM][AsmParser] handles offset expression in parenthesesJian Cai2019-10-142-5/+27
| | | | | | | | | | | | | | | Summary: Integrated assembler does not accept offset expressions surrounded by parenthesis. Handle this case for GAS compability. https://bugs.llvm.org/show_bug.cgi?id=43631 Subscribers: kristof.beyls, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68764 llvm-svn: 374832
* DebugInfo: Remove unnecessary/mistaken inclusion of Bitcode/BitcodeAnalyzer.hDavid Blaikie2019-10-142-4/+0
| | | | | | | | | | | | | | | | Introduced in r374582, Michael Spencer pointed out this broke the modules build due to a missing tblgen dependency on llvm/IR/Attributes.inc. Michael fixed the dependency in r374827. So this removes the inclusion and the new dependency (effectively reverting r374827 and including the alternative fix of removing rather than supporting the new dependency). Thanks for the quick fix/notice, Michael! llvm-svn: 374831
* [update_mir_test_checks] Handle MI flags properlyRoman Tereshin2019-10-1417-189/+192
| | | | | | | | | | | | | | previously we would generate literal check lines w/ no reg-exps for vregs as MI flags (nsw, ninf, etc.) won't be recognized as a part of MI. Fixing that. Includes updating the MIR tests that suffered from the problem. Reviewed By: bogner Differential Revision: https://reviews.llvm.org/D68905 llvm-svn: 374829
* [InstCombine] fold a shifted bool zext to a selectSanjay Patel2019-10-143-8/+10
| | | | | | | | | | | | | | | For a constant shift amount, add the following fold. shl (zext (i1 X)), ShAmt --> select (X, 1 << ShAmt, 0) https://rise4fun.com/Alive/IZ9 Fixes PR42257. Based on original patch by @zvi (Zvi Rackover) Differential Revision: https://reviews.llvm.org/D63382 llvm-svn: 374828
* [Modules Build] Add missing dependency.Michael J. Spencer2019-10-141-0/+3
| | | | | | A previous commit made libLLVMDebugInfoDWARF depend on the LLVM_Bitcode module which depends on the LLVM_intrinsic_gen module which depends on "llvm/IR/Attributes.inc" which is a generated header not depended on by libLLVMDebugInfo. Add that dependency. llvm-svn: 374827
* PR43080: Do not build context-sensitive expressions during name classification.Richard Smith2019-10-1414-178/+417
| | | | | | | | | | | | | | | | | | | | | | | Summary: We don't know what context to use until the classification result is consumed by the parser, which could happen in a different semantic context. So don't build the expression that results from name classification until we get to that point and can handle it properly. This covers everything except C++ implicit class member access, which is a little awkward to handle properly in the face of the protected member access check. But it at least fixes all the currently-filed instances of PR43080. Reviewers: efriedma Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68896 llvm-svn: 374826
* build fix for SBInstruction.Lawrence D'Anna2019-10-143-2/+4
| | | | | | | | | | | | | | oops! I cherry-picked rL374820 thinking it was completely independent of D68737, but it wasn't. It makes an incidental use of SBFile::GetFile, which is introduced there, so I broke the build. The docs say you can commit without review for "obvious". I think this qualifies. If this kind of fix isn't considered obvious, let me know and I'll revert instead. Fixes: rL374820 llvm-svn: 374825
* [lit] Create Run object later and only when it is neededJulian Lettner2019-10-141-30/+31
| | | | | | | | Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D68843 llvm-svn: 374823
OpenPOWER on IntegriCloud