summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* [msan] Check qsort input.Evgenii Stepanov2020-01-062-0/+19
| | | | | | | | | | | | | | | | | | Summary: Qsort interceptor suppresses all checks by unpoisoning the data in the wrapper of a comparator function, and then unpoisoning the output array as well. This change adds an explicit run of the comparator on all elements of the input array to catch any sanitizer bugs. Reviewers: vitalybuka Subscribers: #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D71780
* [NSArray] Remove a very old and deprecated formatter.Davide Italiano2020-01-061-27/+0
| | | | Checked with the Foundation folks.
* [CMake] Pass symlink dependency to add_llvm_install_targets explicitlyPetr Hosek2020-01-061-5/+12
| | | | | | | | | | | | | | | | | | | | The install-${name}-stripped targets don't strip when ${name} is being symlinked, e.g. llvm-ar or llvm-objcopy. The problem is that llvm_install_symlink passes install-${dest} as a dependency of install-${name}, e.g. install-llvm-ar becomes a dependency of both install-llvm-ranlib and install-llvm-ranlib-stripped. What this means is that when installing a distribution that contains both llvm-ar and llvm-ranlib is that first the stripped version of llvm-ar is installed (by the install-llvm-ar-stripped target) and then it's overwritten by an unstripped version of llvm-ar bnecause install-llvm-ranlib-stripped has install-llvm-ranlib as a dependency as mentioned earlier. To avoid this issue, rather than passing the install-${dest} as dependency, we introduce a new argument to add_llvm_install_targets for symlink target which expands it into an appropriate dependency, i.e. install-${dest} for install-${name} target and install-${dest}-stripped for install-${name}-stripped. Differential Revision: https://reviews.llvm.org/D71951
* Don't rely on 'l'(ell) modifiers to indicate a label referenceBill Wendling2020-01-062-20/+45
| | | | | | | | | | | | | | | | Summary: It's not necessary to use an 'l'(ell) modifier when referencing a label. Treat block addresses and MBB references as if the modifier is used anyway. This prevents us from generating references to ficticious labels. Reviewers: jyknight, nickdesaulniers, hfinkel Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71849
* [FileCheck] Remove FileCheck prefix in APIThomas Preud'homme2020-01-063-304/+275
| | | | | | | | | | | | | | | | | | Summary: When FileCheck was made a library, types in the public API were renamed to add a FileCheck prefix, such as Pattern to FileCheckPattern. Many types were moved into a private interface and thus don't need this prefix anymore. This commit removes those unneeded prefixes. Reviewers: jhenderson, jdenny, probinson, grimar, arichardson, rnk Reviewed By: jhenderson Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D72186
* [PowerPC][NFC] Rename record instructions to use _rec suffix instead of oJinsong Ji2020-01-0622-1173/+1216
| | | | | | | | | | | | | | | | | | | We use o suffix to indicate record form instuctions, (as it is similar to dot '.' in mne?) This was fine before, as we did not support XO-form. However, with https://reviews.llvm.org/D66902, we now have XO-form support. It becomes confusing now to still use 'o' for record form, and it is weird to have something like 'Oo' . This patch rename all 'o' instructions to use '_rec' instead. Also rename `isDot` to `isRecordForm`. Reviewed By: #powerpc, hfinkel, nemanjai, steven.zhang, lkail Differential Revision: https://reviews.llvm.org/D70758
* [Diagnostic] make Wmisleading-indendation not warn about labelsTyker2020-01-062-4/+13
| | | | | | | | | | Reviewers: aaron.ballman, xbolva00 Reviewed By: aaron.ballman Subscribers: nickdesaulniers, nathanchance Differential Revision: https://reviews.llvm.org/D72202
* GlobalISel: Fix unsupported legalize actionMatt Arsenault2020-01-063-0/+84
| | | | | | | | This would complain about invalid legalizer rules otherwise. Mark some operations as unsupported for AMDGPU. This currently seems to produce the same legalize error as when no rules are defined, but eventually this should produce a proper user facing error.
* GlobalISel: Correct result type for G_FCMP in lowerFPTOUIMatt Arsenault2020-01-063-37/+84
| | | | | Using the final result type doesn't make any sense. Use the natural default boolean type for the select condition.
* GlobalISel: Start adding computeNumSignBits to GISelKnownBitsMatt Arsenault2020-01-063-0/+152
|
* AMDGPU: Fix legalizing f16 fpowMatt Arsenault2020-01-063-0/+564
| | | | | | The existing test only covered one case for r600. The use of mul_legacy also looks suspicious to me, but leave it for now. The patterns are also not making use of source modifiers.
* AMDGPU: Use ImmLeafMatt Arsenault2020-01-061-2/+2
| | | | | This solves one GlobalISel importer error, but the pattern still fails for another reason.
* AMDGPU: Use ImmLeaf for inline immediate predicatesMatt Arsenault2020-01-066-9/+63
|
* llc/MIR: Fix setFunctionAttributes for MIR functionsMatt Arsenault2020-01-066-63/+167
| | | | | | | | | | | | | | | | | | | | | | | | | | | A random set of attributes are implemented by llc/opt forcing the string attributes on the IR functions before processing anything. This would not happen for MIR functions, which have not yet been created at this point. Use a callback in the MIR parser, purely to avoid dealing with the ugliness that the command line flags are in a .inc file, and would require allowing access to these flags from multiple places (either from the MIR parser directly, or a new utility pass to implement these flags). It would probably be better to cleanup the flag handling into a separate library. This is in preparation for treating more command line flags with a corresponding function attribute in a more uniform way. The fast math flags in particular have a messy system where the command line flag sets the behavior from a function attribute if present, and otherwise the command line flag. This means if any other pass tries to inspect the function attributes directly, it will be inconsistent with the intended behavior. This is also inconsistent with the current behavior of -mcpu and -mattr, which overwrites any pre-existing function attributes. I would like to move this to consistenly have the command line flags not overwrite any pre-existing attributes, and to always ensure the command line flags are consistent with the function attributes.
* [X86] Improve v4i32->v4f64 uint_to_fp for AVX1/AVX2 targets.Craig Topper2020-01-065-95/+88
| | | | | | Use zext+or+fsub to do the conversion. Similar to D71971. Differential Revision: https://reviews.llvm.org/D71971
* [lldb/Docs] Describe optional dependencies on build page.Jonas Devlieghere2020-01-061-5/+31
| | | | | | | List the different CMake flags controlling the optional dependencies as per the discussion on the mailing list: http://lists.llvm.org/pipermail/lldb-dev/2020-January/015867.html
* [LegalizeTypes] Add widening support for STRICT_FSETCC/FSETCCSCraig Topper2020-01-063-0/+394
| | | | | | This patch adds widening which really just scalarizes because we don't have a strategy for the extra elements we would need to pad with. Differential Revision: https://reviews.llvm.org/D72193
* [X86] Rename vec-strict-*-cmp.ll to vec-strict-cmp-*.ll to match other ↵Craig Topper2020-01-063-0/+0
| | | | strict files wich have the size at the end. NFC
* [OPENMP50]Support lastprivate conditional updates in inc/dec unary ops.Alexey Bataev2020-01-067-33/+118
| | | | | Added support for checking of updates of variables used in unary pre(pos) inc/dec expressions.
* [NFC] Test commit, revert whitespace changestevewan2020-01-061-1/+0
| | | | As per the Developer Policy, upon obtaining commit access.
* [NFC] Test commit, whitespace changestevewan2020-01-061-0/+1
| | | | As per the Developer Policy, upon obtaining commit access.
* [x86] add tests for concat self + shuffle; NFCSanjay Patel2020-01-061-0/+64
|
* [OpenMP] Fix incorrect property of __has_attribute() macroKelvin Li2020-01-061-1/+1
| | | | | | | | __has_attribute(fallthough) -> __has_attribute(fallthrough) Submitted by: kiszk (Kazuaki Ishizaki <ishizaki@jp.ibm.com>) Differential Revision: https://reviews.llvm.org/D72287
* Lower TAGPstack with negative offset to SUBG.Evgenii Stepanov2020-01-063-3/+49
| | | | | | | | | | | | | | Summary: This never really occurs in the current codegen, so only a MIR test is possible. Reviewers: ostannard, pcc Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D72123
* [X86] Fix an 8 bit testb being selected when folding a volatile i32 load ↵Amara Emerson2020-01-062-0/+44
| | | | | | pattern. Differential Revision: https://reviews.llvm.org/D71581
* [PowerPC][LoopVectorize] Extend getRegisterClassForType to consider double ↵Jinsong Ji2020-01-062-9/+18
| | | | | | | | | | | | | | and other floating point type In https://reviews.llvm.org/D67148, we use isFloatTy to test floating point type, otherwise we return GPRRC. So 'double' will be classified as GPRRC, which is not accurate. This patch covers other floating point types. Reviewed By: #powerpc, nemanjai Differential Revision: https://reviews.llvm.org/D71946
* [lld] Fix trivial typos in commentsKazuaki Ishizaki2020-01-0631-46/+46
| | | | | | Reviewed By: ruiu, MaskRay Differential Revision: https://reviews.llvm.org/D72196
* [libc] Move all tests to a top level `test` directory.Siva Chandra Reddy2020-01-0622-60/+89
| | | | | | | | | | A toplevel target, `check-libc` has also been added. Reviewers: abrachet, phosek Tags: #libc-project Differential Revision: https://reviews.llvm.org/D72177
* [lldb/Docs] Fix capitalization typo.Jonas Devlieghere2020-01-061-1/+1
| | | | This has been bothering me for way too long.
* [lldb/CMake] Only set PYTHON_HOME on WindowsJonas Devlieghere2020-01-061-1/+1
| | | | | | My earlier change for Python auto-detection caused PYTHON_HOME to be set unconditionally, while before the change this only happened for Windows. This caused the PythonDataObjectsTest to fail with an import error.
* [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
OpenPOWER on IntegriCloud