summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* [CMake] Add $ORIGIN/../../../../lib to rpath if BUILD_SHARED_LIBS or ↵Fangrui Song2020-01-061-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | LLVM_LINK_LLVM_DYLIB on *nix Summary: lib/python2.7/dist-packages/lldb/_lldb.so is a symlink to lib/liblldb.so, which depends on lib/libLLVM*.so (-DBUILD_SHARED_LIBS=ON) or lib/libLLVM-10git.so (-DLLVM_LINK_LLVM_DYLIB=ON). Add an additional rpath `$ORIGIN/../../../../lib` so that _lldb.so can be loaded from Python. This fixes an import error from lib/python2.7/dist-packages/lldb/__init__.py from . import _lldb ImportError: libLLVMAArch64CodeGen.so.10git: cannot open shared object file: No such file or directory The following configurations will work: * -DBUILD_SHARED_LIBS=ON * -DBUILD_SHARED_LIBS=OFF -DLLVM_LINK_LLVM_DYLIB=ON * -DBUILD_SHARED_LIBS=OFF -DLLVM_LINK_LLVM_DYLIB=ON -DCLANG_LINK_CLANG_DYLIB=ON (-DCLANG_LINK_CLANG_DYLIB=ON depends on -DLLVM_LINK_LLVM_DYLIB=ON) Reviewed By: labath Differential Revision: https://reviews.llvm.org/D71800
* Make check-llvm run 50% faster on macOS, 18% faster on Windows.Nico Weber2020-01-061-6/+30
| | | | | | | | | | | | | | | | | | | | While looking at cycle time graphs of some of my bots, I noticed that 327894859cc made check-llvm noticeably slower on macOS and Windows. As it turns out, the 5 substitutions added in that change were enough to cause lit to thrash the build-in cache in re.compile() (re.sub() is implemented as re.compile().sub()), and apparently applySubstitutions() is on the cricital path and slow when all regexes need to compile all the time. (See `_MAXCACHE = 512` in cpython/Lib/re.py) Supporting full regexes for lit substitutions seems a bit like overkill, but for now add a simple unbounded cache to recover the lost performance. No intended behavior change.
* [lldb/Test] Move @skipIfAsan from test class to test methods.Jonas Devlieghere2020-01-061-1/+2
| | | | skipTestIfFn can only be used to decorate a test method.
* [llvm-readelf] Print EI_ABIVERSION as decimal instead of hexadecimalFangrui Song2020-01-065-12/+12
| | | | | | | | This matches GNU readelf and llvm-readobj. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D72234
* [gn build] Port 350da402ef6LLVM GN Syncbot2020-01-061-0/+1
|
* [clang-tidy] new check: bugprone-signed-char-misuseTamás Zolnai2020-01-0611-0/+458
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This check searches for signed char -> integer conversions which might indicate programming error, because of the misinterpretation of char values. A signed char might store the non-ASCII characters as negative values. The human programmer probably expects that after an integer conversion the converted value matches with the character code (a value from [0..255]), however, the actual value is in [-128..127] interval. See also: STR34-C. Cast characters to unsigned char before converting to larger integer sizes <https://wiki.sei.cmu.edu/confluence/display/c/STR34-C.+Cast+characters+to+unsigned+char+before+converting+to+larger+integer+sizes> By now this check is limited to assignment / variable declarations. If we would catch all signed char -> integer conversion, then it would produce a lot of findings and also false positives. So I added only this use case now, but this check can be extended with additional use cases later. The CERT documentation mentions another use case when the char is used for array subscript. Next to that a third use case can be the signed char - unsigned char comparison, which also a use case where things happen unexpectedly because of conversion to integer. Reviewers: alexfh, hokein, aaron.ballman Reviewed By: aaron.ballman Subscribers: sylvestre.ledru, whisperity, Eugene.Zelenko, mgorny, xazax.hun, cfe-commits Tags: #clang, #clang-tools-extra Differential Revision: https://reviews.llvm.org/D71174
* [lldb/Test] Temporarily skip TestFoundationDisassembly on the ASan bot.Jonas Devlieghere2020-01-061-0/+1
| | | | | This test is timing out on the sanitized bot on GreenDragon. Temporarily disable it to increase the signal-to-noise ration.
* [lldb/CMake] Autodetect Python dependencyJonas Devlieghere2020-01-063-48/+107
| | | | | | | | Python was the last remaining "optional" dependency for LLDB. This moves the code to find Python into FindPythonInterpAndLibs using the same principles as FindCursesAndPanel. Differential revision: https://reviews.llvm.org/D72107
* [AIX] Use csect reference for function address constantsdiggerlin2020-01-061-1/+1
| | | | | | | | | | | | | | | | | | | | SUMMARY: We currently emit a reference for function address constants as labels; for example: foo_ptr: .long foo however, there may be no such label in the case where the function is undefined. Although the label exists when the function is defined, we will (to be consistent) also use a csect reference in that case. Address one comment https://reviews.llvm.org/D71144#inline-653255 Reviewers: daltenty,hubert.reinterpretcast,jasonliu,Xiangling_L Subscribers: cebowleratibm, wuzish, nemanjai Differential Revision: https://reviews.llvm.org/D71144
* [llvm-libc] Fix missing virtual destructorGuillaume Chatelet2020-01-063-0/+18
| | | | | | | | | | | | Summary: This patch adds a virtual destructor to the Command class. Reviewers: sivachandra Subscribers: mgorny, MaskRay, libc-commits Tags: #libc-project Differential Revision: https://reviews.llvm.org/D72253
* [ARM] Use the correct opcodes for Thumb2 segmented stack frame loweringDavid Green2020-01-062-27/+65
| | | | | | | | | The segmented stack lowering code appears to be using ARM opcodes under Thumb2. The MRC opcode will be the same for Thumb and ARM, but t2LDR seems wrong. Either way, using the correct thumb vs arm opcodes is more correct. Differential Revision: https://reviews.llvm.org/D72074
* [ARM] Use correct TRAP opcode for thumb in FastISelDavid Green2020-01-062-3/+7
| | | | | | | | | We were previously unconditionally using the ARM::TRAP opcode, even under Thumb. My understanding is that these are essentially the same thing (they both result in a trap under Thumb), but the ARM::TRAP opcode is marked as requiring IsARM, so it is more correct to use ARM::tTRAP. Differential Revision: https://reviews.llvm.org/D72075
* [AIX] Use csect reference for function address constantsdiggerlin2020-01-062-0/+54
| | | | | | | | | | | | | | | | | SUMMARY: We currently emit a reference for function address constants as labels; for example: foo_ptr: .long foo however, there may be no such label in the case where the function is undefined. Although the label exists when the function is defined, we will (to be consistent) also use a csect reference in that case. Reviewers: daltenty,hubert.reinterpretcast,jasonliu,Xiangling_L Subscribers: cebowleratibm, wuzish, nemanjai Differential Revision: https://reviews.llvm.org/D71144
* Adds -Wrange-loop-analysis to -WallMark de Wever2020-01-063-2/+5
| | | | | | | | | | This makes the range loop warnings part of -Wall. Fixes PR32823: Warn about accidental coping of data in range based for Differential Revision: https://reviews.llvm.org/D68912 Recomitted after fixing the warnings it created.
* [NFC] Fixes -Wrange-loop-analysis warningsMark de Wever2020-01-062-2/+2
| | | | | | This avoids new warnings due to D68912 adds -Wrange-loop-analysis to -Wall. Differential Revision: https://reviews.llvm.org/D72210
* [AMDGPU] Fix "use of uninitialized variable" static analyzer warning. NFCI.Simon Pilgrim2020-01-061-0/+1
| | | | Add "unreachable" default case to AMDGPUTargetStreamer::getArchNameFromElfMach
* Fix "use of uninitialized variable" static analyzer warnings. NFCI.Simon Pilgrim2020-01-061-0/+2
| | | | Add "unreachable" default cases like we do for the other switch()s in X86MCInstLower::Lower
* Fix "use of uninitialized variable" static analyzer warning. NFCI.Simon Pilgrim2020-01-061-1/+1
|
* [ARM,MVE] Fix many signedness errors in MVE intrinsics.Simon Tatham2020-01-0631-401/+432
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Running an end-to-end test last week I noticed that a lot of the ACLE intrinsics that operate differently on vectors of signed and unsigned integers were ending up generating the signed version of the instruction unconditionally. This is because the IR intrinsics had no way to distinguish signed from unsigned: the LLVM type system just calls them both `v8i16` (or whatever), so you need either separate intrinsics for signed and unsigned, or a flag parameter that tells ISel which one to choose. This patch fixes all the problems of that kind that I've noticed, by adding an i32 flag parameter to many of the IR intrinsics which is set to 1 for unsigned (matching the existing practice in cases where we got it right), and conditioning all the isel patterns on that flag. So the fundamental change is in `IntrinsicsARM.td`, changing the low-level IR intrinsics API; there are knock-on changes in `arm_mve.td` (adjusting code gen for the ACLE intrinsics to use the modified API) and in `ARMInstrMVE.td` (adjusting isel to expect the new unsigned flags). The rest of this patch is boringly updating tests. Reviewers: dmgreen, miyuki, MarkMurrayARM Reviewed By: dmgreen Subscribers: kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D72270
* [ARM,MVE] Support -ve offsets in gather-load intrinsics.Simon Tatham2020-01-065-66/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The ACLE intrinsics with `gather_base` or `scatter_base` in the name are wrappers on the MVE load/store instructions that take a vector of base addresses and an immediate offset. The immediate offset can be up to 127 times the alignment unit, and it can be positive or negative. At the MC layer, we got that right. But in the Sema error checking for the wrapping intrinsics, the offset was erroneously constrained to be positive. To fix this I've adjusted the `imm_mem7bit` class in the Tablegen that defines the intrinsics. But that causes integer literals like `0xfffffffffffffe04` to appear in the autogenerated calls to `SemaBuiltinConstantArgRange`, which provokes a compiler warning because that's out of the non-overflowing range of an `int64_t`. So I've also tweaked `MveEmitter` to emit that as `-0x1fc` instead. Updated the tests of the Sema checks themselves, and also adjusted a random sample of the CodeGen tests to actually use negative offsets and prove they get all the way through code generation without causing a crash. Reviewers: dmgreen, miyuki, MarkMurrayARM Reviewed By: dmgreen Subscribers: kristof.beyls, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D72268
* [ARM,MVE] Generate the right instruction for vmaxnmq_m_f16.Simon Tatham2020-01-063-6/+6
| | | | | | | | | | | | | | | | | Summary: Due to a copy-paste error in the isel patterns, the predicated version of this intrinsic was expanding to the `VMAXNMT.F32` instruction instead of `VMAXNMT.F16`. Similarly for vminnm. Reviewers: dmgreen, miyuki, MarkMurrayARM Reviewed By: dmgreen Subscribers: kristof.beyls, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D72269
* AMDGPU/GlobalISel: Select scalar v2s16 G_BUILD_VECTORMatt Arsenault2020-01-065-25/+280
|
* [lldb] [Process/NetBSD] Remove unused orig_*ax useMichał Górny2020-01-061-5/+0
| | | | | | | orig_*ax logic is Linux-specific, and was never used on NetBSD. In fact, its support seems to be a dead code entirely. Differential Revision: https://reviews.llvm.org/D72195
* AMDGPU/GlobalISel: Select more G_EXTRACTs correctlyMatt Arsenault2020-01-062-5/+39
| | | | | | | | This assumed a 32-bit extract size, which would produce invalid copies with 64-bit extracts. Handle the easy case. Ideally we would have a way to get the proper subreg index for any 32-bit offset, but there should probably be a tablegenerated way of getting the subreg index for any size and offset.
* [mlir][Linalg] Reimplement and extend getStridesAndOffsetNicolas Vasilache2020-01-062-130/+126
| | | | | | | | | | | | | | | | | | Summary: This diff reimplements getStridesAndOffset in a significantly simpler way by operating on the AffineExpr and calling into simplifyAffineExpr instead of rolling its own saturating arithmetic. As a consequence it becomes quite simple to extend the behavior of getStridesAndOffset to encompass more cases by manipulating the AffineExpr more directly. The divisions are still filtered out and continue to yield fully dynamic strides. Simplifying the divisions is left for a later time if compelling use cases arise. Relevant tests are added. Reviewers: ftynse Subscribers: mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, arpith-jacob, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D72098
* [clang-format] fix conflict between FormatStyle::BWACS_MultiLine and ↵Mitchell Balan2020-01-062-1/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BeforeCatch/BeforeElse Summary: Found a bug introduced with BraceWrappingFlags AfterControlStatement MultiLine. This feature conflicts with the existing BeforeCatch and BeforeElse flags. For example, our team uses BeforeElse. if (foo || bar) { doSomething(); } else { doSomethingElse(); } If we enable MultiLine (which we'd really love to do) we expect it to work like this: if (foo || bar) { doSomething(); } else { doSomethingElse(); } What we actually get is: if (foo || bar) { doSomething(); } else { doSomethingElse(); } Reviewers: MyDeveloperDay, Bouska, mitchell-stellar Patch by: pastey Subscribers: Bouska, cfe-commits Tags: clang Differential Revision: https://reviews.llvm.org/D71939
* [X86] Add extra PR43971 test case mentioned in D70267Simon Pilgrim2020-01-061-0/+45
|
* [CostModel][X86] Add missing scalar i64->f32 uitofp costsSimon Pilgrim2020-01-062-11/+15
|
* [DAG] DAGCombiner::XformToShuffleWithZero - use APInt::extractBits helper. NFCI.Simon Pilgrim2020-01-061-8/+4
|
* [test][DebugInfo][NFC] Rename method for clarityJames Henderson2020-01-061-18/+20
| | | | | | | | | | The checkGetOrParseLineTableEmitsError function could end up generating both recoverable and unrecoverable errors, but it is only intended for handling the latter. Reviewed by: dblaikie Differential Revision: https://reviews.llvm.org/D72156
* [NFC] Fix trivial typos in commentsJames Henderson2020-01-0656-69/+69
| | | | | | | | Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D72143 Patch by Kazuaki Ishizaki.
* Fix MSVC "not all control paths return a value" warning. NFCI.Simon Pilgrim2020-01-061-0/+1
|
* [ARM][MVE] More MVETailPredication debug messages. NFC.Sjoerd Meijer2020-01-062-65/+96
| | | | | | | | | | I've added a few more debug messages to MVETailPredication because I wanted to trace better which instructions are added/removed. And while I was at it, I factored out one function which I thought was clearer, and have added some comments to describe better the flow between MVETailPredication and ARMLowOverheadLoops. Differential Revision: https://reviews.llvm.org/D71549
* Add interface emitPrefix for MCCodeEmitterShengchen Kan2020-01-062-89/+139
| | | | Differential Revision: https://reviews.llvm.org/D72047
* [APFloat] Fix compilation warningsEhud Katz2020-01-065-26/+21
|
* [mlir] Update mlir/CMakeLists.txt to install *.def filesKern Handa2020-01-061-0/+1
| | | | | | | This is needed to consume mlir after it has been installed of the source tree. Without this, consuming mlir results a build error. Differential Revision: https://reviews.llvm.org/D72232
* Add ExternalAAWrapperPass to createLegacyPMAAResults.Neil Henning2020-01-061-0/+5
| | | | | | | | | | | | | | | Our out-of-tree custom aliasing solution for the HPC# Burst compiler here at Unity makes use of the `ExternalAAwrapperPass` infrastructure to insert our custom aliasing resolution into the core of LLVM. This is great for all cases except for function inlining, where because `createLegacyPMAAResults` does not make use of `ExternalAAWrapperPass`, when we have a definite no-alias result within a function it won't be propagated to the calling function during inlining. This commit just rectifies this oversight by adding the missing dependency. Differential Revision: https://reviews.llvm.org/D71348
* [APFloat] Add recoverable string parsing errors to APFloatEhud Katz2020-01-068-196/+256
| | | | | | Implementing the APFloat part in PR4745. Differential Revision: https://reviews.llvm.org/D69770
* [Metadata] Add TBAA struct metadata to `AAMDNode`Anton Afanasyev2020-01-064-21/+27
| | | | | | | | | | | | | | | | | | | Summary: Make `AAMDNodes`' `getAAMetadata()` and `setAAMetadata()` to take `!tbaa.struct` into account as well as `!tbaa`. This impacts llvm.org/pr42022. This is a temprorary fix needed to keep `!tbaa.struct` tag by SROA pass. New field `TBAAStruct` should be deleted when `!tbaa` tag replaces `!tbaa.struct`. Merging two `!tbaa.struct`'s to one is conservatively considered to be `nullptr` (giving `MayAlias`) -- this could be enhanced, but relying on the said future replacement. Reviewers: RKSimon, spatel, vporpo Subscribers: hiraditya, kosarev, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70924
* [Clang] Force rtlib=platform in test to avoid fails with CLANG_DEFAULT_RTLIBKristina Brooks2020-01-061-0/+3
| | | | | | | | | | | | | | | | | | Driver test `cross-linux.c` fails when CLANG_DEFAULT_RTLIB is "compiler-rt" as the it expects a GCC-style `"crtbegin.o"` after `"crti.o"` but instead receives something akin to this in the frontend invocation: ``` "crt1.o" "crti.o" "/o/b/llvm/bin/../lib/clang/10.0.0/lib/linux/clang_rt.crtbegin-x86_64.o" ``` This patch adds an override to `cross-linux.c` tests so the expected result is produced regardless of the compile-time default rtlib, as having tests fail due to that is fairly confusing. After applying the patch, the test passes regardless of the CLANG_DEFAULT_RTLIB setting. Differential Revision: https://reviews.llvm.org/D72236
* [TargetLowering] Use SETCC input type to call getBooleanContents instead of ↵Craig Topper2020-01-051-1/+1
| | | | | | | | | the setcc result type. This isn't a functonal change since we also check the bit width is the same and the input type is integer. This guarantees the input and output type are the same. But passing the input type makes the code more readable.
* [mlir][spirv] Update SPIR-V documentation with information aboutMaheshRavishankar2020-01-051-6/+113
| | | | | | | | | lowering to SPIR-V dialect. Add information about - SPIRVTypeConverter - SPIRVOpLowering - Utility functions used in lowering to SPIR-V dialect.
* [MC] Reorder members of MCFragment's subclasses to decrease paddingFangrui Song2020-01-051-54/+14
| | | | | | | | | On a 64-bit platform: sizeof(MCBoundaryAlignFragment): 64 -> 56 sizeof(MCOrgFragment): 72 -> 64 sizeof(MCFillFragment): 80 -> 72 sizeof(MCLEBFragment): 88 -> 80
* [MC] Reorder MCFragment members to decrease paddingFangrui Song2020-01-052-17/+8
| | | | | | | sizeof(MCFragment) does not change, but some if its subclasses do, e.g. on a 64-bit platform, sizeof(MCEncodedFragment) decreases from 64 to 56, sizeof(MCDataFragment) decreases from 224 to 216.
* [DAGCombine] Don't check the legality of type when combine the SIGN_EXTEND_INREGQingShan Zhang2020-01-062-6/+4
| | | | | | | | | | | | | | | | | | | | | | This is the DAG node for SIGN_EXTEND_INREG : t21: v4i32 = sign_extend_inreg t18, ValueType:ch:v4i16 It has two operands. The first one is the value it want to extend, and the second one is the type to specify how to extend the value. For this example, it means that, it is signed extend the t18(v4i32) from v4i16 to v4i32. That is the semantics of c code: vector int foo(vector int m) { return m << 16 >> 16; } And it could be any vector type that hardware support the operation, though the type 'v4i16' is NOT legal for the target. When we are trying to combine the srl + sra, what we did now is calling the TLI.isOperationLegal(), which will also check the legality of the type. That doesn't make sense. Differential Revision: https://reviews.llvm.org/D70230
* [MC] Delete MCFragment::isDummy. NFCFangrui Song2020-01-052-4/+1
| | | | | isa<...>, dyn_cast<...> and cast<...> are used by other fragments. Don't make MCDummyFragment special.
* [X86] Improve v2i64->v2f32 and v4i64->v4f32 uint_to_fp on avx and avx2 targets.Craig Topper2020-01-055-638/+514
| | | | | | | | | | | | | | | | | | | | | Summary: Based on Simon's D52965, but improved to handle strict fp and improve some of the shuffling. Rather than use v2i1/v4i1 and let type legalization continue, just generate all the code with legal types and use an explicit shuffle. I also added an explicit setcc to the v4i64 code to match the semantics of vselect which doesn't just use the sign bit. I'm also using a v4i64->v4i32 truncate instead of the shuffle in Simon's original code. With the setcc this will become a pack. Future work can look into using X86ISD::BLENDV and a different shuffle that only moves the sign bit. Reviewers: RKSimon, spatel Reviewed By: RKSimon Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71956
* [NFC] Modify the format:Liu, Chen32020-01-061-2/+1
| | | | Drop the else since we alerady returned in the if.
* [Coroutines] Remove corresponding phi values when apply ↵Brian Gesiak2020-01-053-12/+133
| | | | | | | | | | | | | | | | | | | | | | | | | | | simplifyTerminatorLeadingToRet Summary: In addMustTailToCoroResumes, we set musttail on those resume instructions that are followed by a ret instruction. This is done by simplifyTerminatorLeadingToRet which replace a sequence of branches leading to a ret with a clone of the ret. However it forgets to remove corresponding PHI values that come from basic block of replaced branch, and may cause jumpthreading pass hangs (https://bugs.llvm.org/show_bug.cgi?id=43720) This patch fix this issue Test Plan: cppcoro library with O3+flto check-llvm Reviewers: modocache, GorNishanov, lewissbaker Reviewed By: modocache Subscribers: mehdi_amini, EricWF, hiraditya, dexonsmith, jfb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71826 Patch by junparser (JunMa)!
* Clang-format previous commitStephen Kelly2020-01-051-3/+1
|
OpenPOWER on IntegriCloud