summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* [tsan] Don't delay SIGTRAP handlerVitaly Buka2019-10-072-4/+34
| | | | | | | | | | | | Reviewers: eugenis, jfb Subscribers: #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D68604 llvm-svn: 373978
* Add VFS support for sanitizers' blacklistJan Korous2019-10-073-1/+44
| | | | | | Differential Revision: https://reviews.llvm.org/D67742 llvm-svn: 373977
* [X86] Add new calling convention that guarantees tail call optimizationReid Kleckner2019-10-0731-19/+703
| | | | | | | | | | | | | | | | | When the target option GuaranteedTailCallOpt is specified, calls with the fastcc calling convention will be transformed into tail calls if they are in tail position. This diff adds a new calling convention, tailcc, currently supported only on X86, which behaves the same way as fastcc, except that the GuaranteedTailCallOpt flag does not need to enabled in order to enable tail call optimization. Patch by Dwight Guth <dwight.guth@runtimeverification.com>! Reviewed By: lebedev.ri, paquette, rnk Differential Revision: https://reviews.llvm.org/D67855 llvm-svn: 373976
* [WebAssembly] Fix unwind mismatch stat computationHeejin Ahn2019-10-072-3/+9
| | | | | | | | | | | | | | | | | | | | | | Summary: There was a bug when computing the number of unwind destination mismatches in CFGStackify. When there are many mismatched calls that share the same (original) destination BB, they have to be counted separately. This also fixes a typo and runs `fixUnwindMismatches` only when the wasm exception handling is enabled. This is to prevent unnecessary computations and does not change behavior. Reviewers: dschuff Subscribers: sbc100, jgravelle-google, hiraditya, sunfish, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68552 llvm-svn: 373975
* [llvm-lipo] Add TextAPI to LINK_COMPONENTSHeejin Ahn2019-10-071-0/+1
| | | | | | | | | | | | | | | | Summary: D68319 uses `MachO::getCPUTypeFromArchitecture` and without this builds with `-DBUILD_SHARED_LIBS=ON` fail. Reviewers: alexshap Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68594 llvm-svn: 373974
* [Diagnostics] Emit better -Wbool-operation's warning message if we known ↵David Bolvansky2019-10-074-8/+12
| | | | | | that the result is always true llvm-svn: 373973
* [Attributor][FIX] Remove assertion wrong for on invalid IRPositionsJohannes Doerfert2019-10-071-2/+0
| | | | llvm-svn: 373972
* [libc++] Remove C++03 variadics in shared_ptr (v2)Zoe Carver2019-10-071-70/+0
| | | | | | | | | | | | | | Summary: In my last patch (D67675) I forgot a few variadics. This patch removes the remaining make_shared and allocate_shared C++03 variadics. Reviewers: ldionne, EricWF, mclow.lists Subscribers: christof, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D68000 llvm-svn: 373971
* [CMake] We only want to copy the headers for macOS.Davide Italiano2019-10-071-0/+2
| | | | | | <rdar://problem/55916729> llvm-svn: 373970
* [llvm-c] Add UnaryOperator to LLVM_FOR_EACH_VALUE_SUBCLASS macroCameron McInally2019-10-071-0/+1
| | | | | | | | Note that we are not sure where the tests for these functions lives. This was discussed in the Phab Diff. Differential Revision: https://reviews.llvm.org/D68588 llvm-svn: 373969
* Mark constructor as default and remove implementation (NFC)Adrian Prantl2019-10-072-3/+1
| | | | llvm-svn: 373968
* [WebAssembly] Add memory intrinsics handling to mayThrow()Heejin Ahn2019-10-072-1/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously, `WebAssembly::mayThrow()` assumed all inputs are global addresses. But when intrinsics, such as `memcpy`, `memmove`, or `memset` are lowered to external symbols in instruction selection and later emitted as library calls. And these functions don't throw. This patch adds handling to those memory intrinsics to `mayThrow` function. But while most of libcalls don't throw, we can't guarantee all of them don't throw, so currently we conservatively return true for all other external symbols. I think a better way to solve this problem is to embed 'nounwind' info in `TargetLowering::CallLoweringInfo`, so that we can access the info from the backend. This will also enable transferring 'nounwind' properties of LLVM IR instructions. Currently we don't transfer that info and we can only access properties of callee functions, if the callees are within the module. Other targets don't need this info in the backend because they do all the processing before isel, but it will help us because that info will reduce code size increase in fixing unwind destination mismatches in CFGStackify. But for now we return false for these memory intrinsics and true for all other libcalls conservatively. Reviewers: dschuff Subscribers: sbc100, jgravelle-google, hiraditya, sunfish, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68553 llvm-svn: 373967
* [llvm-lipo] Relax the check of the specified input file architectureAlexander Shaposhnikov2019-10-071-6/+12
| | | | | | | | | | | | cctools lipo only compares the cputypes when it verifies that the specified (via -arch) input file and the architecture match. This diff adjusts the behavior of llvm-lipo accordingly. Differential revision: https://reviews.llvm.org/D68319 Test plan: make check-all llvm-svn: 373966
* [Attributor] Deduce memory behavior of functions and argumentsJohannes Doerfert2019-10-0717-163/+710
| | | | | | | | | | | | | | | Deduce the memory behavior, aka "read-none", "read-only", or "write-only", for functions and arguments. Reviewers: sstefan1, uenoku Subscribers: hiraditya, bollu, jfb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67384 llvm-svn: 373965
* [InstCombine] Fold conditional sign-extend of high-bit-extract into ↵Roman Lebedev2019-10-072-19/+129
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | high-bit-extract-with-signext (PR42389) This can come up in Bit Stream abstractions. The pattern looks big/scary, but it can't be simplified any further. It only is so simple because a number of my preparatory folds had happened already (shift amount reassociation / shift amount reassociation in bit test, sign bit test detection). Highlights: * There are two main flavors: https://rise4fun.com/Alive/zWi The difference is add vs. sub, and left-shift of -1 vs. 1 * Since we only change the shift opcode, we can preserve the exact-ness: https://rise4fun.com/Alive/4u4 * There can be truncation after high-bit-extraction: https://rise4fun.com/Alive/slHc1 (the main pattern i'm after!) Which means that we need to ignore zext of shift amounts and of NBits. * The sign-extending magic can be extended itself (in add pattern via sext, in sub pattern via zext. not the other way around!) https://rise4fun.com/Alive/NhG (or those sext/zext can be sinked into `select`!) Which again means we should pay attention when matching NBits. * We can have both truncation of extraction and widening of magic: https://rise4fun.com/Alive/XTw In other words, i don't believe we need to have any checks on bitwidths of any of these constructs. This is worsened in general by the fact that we may have `sext` instead of `zext` for shift amounts, and we don't yet canonicalize to `zext`, although we should. I have not done anything about that here. Also, we really should have something to weed out `sub` like these, by folding them into `add` variant. https://bugs.llvm.org/show_bug.cgi?id=42389 llvm-svn: 373964
* [InstCombine][NFC] Tests for "conditional sign-extend of high-bit-extract" ↵Roman Lebedev2019-10-071-0/+1040
| | | | | | | | pattern (PR42389) https://bugs.llvm.org/show_bug.cgi?id=42389 llvm-svn: 373963
* [InstCombine] Move isSignBitCheck(), handle rest of the predicatesRoman Lebedev2019-10-072-28/+39
| | | | | | | | | True, no test coverage is being added here. But those non-canonical predicates that are already handled here already have no test coverage as far as i can tell. I tried to add tests for them, but all the patterns already get handled elsewhere. llvm-svn: 373962
* [InstCombine][NFC] dropRedundantMaskingOfLeftShiftInput(): change how we ↵Roman Lebedev2019-10-071-70/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | deal with mask Summary: Currently, we pre-check whether we need to produce a mask or not. This involves some rather magical constants. I'd like to extend this fold to also handle the situation when there's also a `trunc` before outer shift. That will require another set of magical constants. It's ugly. Instead, we can just compute the mask, and check whether mask is a pass-through (all-ones) or not. This way we don't need to have any magical numbers. This change is NFC other than the fact that we now compute the mask and then check if we need (and can!) apply it. Reviewers: spatel Reviewed By: spatel Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68470 llvm-svn: 373961
* [InstCombine] dropRedundantMaskingOfLeftShiftInput(): propagate undef shift ↵Roman Lebedev2019-10-076-5/+38
| | | | | | | | | | | | | | | | | | | | | | amounts Summary: When we do `ConstantExpr::getZExt()`, that "extends" `undef` to `0`, which means that for patterns a/b we'd assume that we must not produce any bits for that channel, while in reality we simply didn't care about that channel - i.e. we don't need to mask it. Reviewers: spatel Reviewed By: spatel Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68239 llvm-svn: 373960
* [Bitcode] Update naming of UNOP_NEG to UNOP_FNEGCameron McInally2019-10-073-3/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D68588 llvm-svn: 373958
* [debugserver] Include the correct header.Davide Italiano2019-10-071-1/+1
| | | | | | <rdar://problem/55916729> llvm-svn: 373957
* [AccelTable] Remove stale comment (NFC)Jonas Devlieghere2019-10-071-2/+0
| | | | | | rdar://55857228 llvm-svn: 373956
* [test] Rename `Modules` to `ObjectFile` (NFC)Jonas Devlieghere2019-10-0762-0/+0
| | | | llvm-svn: 373955
* [MachO] Shuffle some things around in ParseSymtab (NFC)Jonas Devlieghere2019-10-071-5/+4
| | | | llvm-svn: 373954
* [gdb-remote] process properly effective uidWalter Erquinigo2019-10-072-3/+7
| | | | | | | | | | | | | | | | | | Summary: Someone wrote SetEffectiveSetEffectiveGroupID instead of SetEffectiveUserID. After this fix, the android process list can show user names, e.g. ``` PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE ARGUMENTS ====== ====== ========== ========== ========== ========== ============================== ============================ 529 1 root 0 root 0 /sbin/ueventd ``` Reviewers: labath,clayborg,aadsm,xiaobai Subscribers: llvm-svn: 373953
* [OPENMP]Fix caonical->canonical, NFC.Alexey Bataev2019-10-072-4/+4
| | | | | | Fixed typo. llvm-svn: 373952
* Attempt to fix a few clang-tidy tests on Windows, see PR43593.Nico Weber2019-10-074-4/+4
| | | | llvm-svn: 373951
* Fix for expanding __pragmas in macro argumentsAmy Huang2019-10-072-33/+58
| | | | | | | | | | | | | | | | | Summary: Avoid parsing __pragma into an annotation token when macro arguments are pre-expanded. This is what clang currently does when parsing _Pragmas. Fixes https://bugs.llvm.org/show_bug.cgi?id=41128, where clang crashed when trying to get the length of an annotation token. Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68114 llvm-svn: 373950
* [libc++abi] Introduce a LIBCXXABI_LIBRARY_VERSION optionLouis Dionne2019-10-072-1/+6
| | | | | | | | That option controls the 'VERSION' attribute of the libc++abi shared library, which in turn controls the name of the actual dylib being produced. llvm-svn: 373949
* gn build: try to make system-libs.windows.test passNico Weber2019-10-071-1/+1
| | | | llvm-svn: 373948
* AMDGPU/GlobalISel: Handle more G_INSERT casesMatt Arsenault2019-10-074-77/+185
| | | | | | | | | Start manually writing a table to get the subreg index. TableGen should probably generate this, but I'm not sure what it looks like in the arbitrary case where subregisters are allowed to not fully cover the super-registers. llvm-svn: 373947
* GlobalISel: Partially implement lower for G_INSERTMatt Arsenault2019-10-074-13/+193
| | | | llvm-svn: 373946
* AMDGPU/GlobalISel: Fix selection of 16-bit shiftsMatt Arsenault2019-10-074-297/+816
| | | | llvm-svn: 373945
* AMDGPU/GlobalISel: Select VALU G_AMDGPU_FFBH_U32Matt Arsenault2019-10-072-8/+8
| | | | llvm-svn: 373944
* AMDGPU/GlobalISel: Use S_MOV_B64 for inline constantsMatt Arsenault2019-10-073-31/+39
| | | | | | | This hides some defects in SIFoldOperands when the immediates are split. llvm-svn: 373943
* AMDGPU/GlobalISel: Widen 16-bit G_MERGE_VALUEs sourcesMatt Arsenault2019-10-078-5469/+11866
| | | | | | Continue making a mess of merge/unmerge legality. llvm-svn: 373942
* [libc++abi] Do not define -Dcxxabi_shared_EXPORTS when building libc++abiLouis Dionne2019-10-071-1/+3
| | | | | | | CMake sets adds that definition automatically, but we don't need or use it. llvm-svn: 373940
* [OPENMP50]Treat range-based for as canonical loop.Alexey Bataev2019-10-0727-42/+291
| | | | | | | According to OpenMP 5.0, range-based for is also considered as a canonical form of loops. llvm-svn: 373939
* AMDGPU/GlobalISel: Select more G_INSERT casesMatt Arsenault2019-10-072-42/+503
| | | | | | | | | | At minimum handle the s64 insert type, which are emitted in real cases during legalization. We really need TableGen to emit something to emit something like the inverse of composeSubRegIndices do determine the subreg index to use. llvm-svn: 373938
* GlobalISel: Add target pre-isel instructionsMatt Arsenault2019-10-0715-6/+140
| | | | | | | | | | | | | | Allows targets to introduce regbankselectable pseudo-instructions. Currently the closet feature to this is an intrinsic. However this requires creating a public intrinsic declaration. This litters the public intrinsic namespace with operations we don't necessarily want to expose to IR producers, and would rather leave as private to the backend. Use a new instruction bit. A previous attempt tried to keep using enum value ranges, but it turned into a mess. llvm-svn: 373937
* [clang] [cmake] Support LLVM_DISTRIBUTION_COMPONENTS in stand-alone buildMichal Gorny2019-10-071-0/+5
| | | | | | Differential Revision: https://reviews.llvm.org/D68412 llvm-svn: 373936
* Second attempt to add iterator_range::empty()Jordan Rose2019-10-0719-32/+33
| | | | | | | | | | | | Doing this makes MSVC complain that `empty(someRange)` could refer to either C++17's std::empty or LLVM's llvm::empty, which previously we avoided via SFINAE because std::empty is defined in terms of an empty member rather than begin and end. So, switch callers over to the new method as it is added. https://reviews.llvm.org/D68439 llvm-svn: 373935
* [libc++abi] Remove redundant link flags on Apple platformsLouis Dionne2019-10-071-18/+1
| | | | | | | | | | | | | | | These flags are already set when we create the cxxabi_shared target using the SOVERSION and VERSION target properties, and the install_name was already being overriden to '@rpath/libc++abi.1.dylib' by CMake because no 'CMAKE_INSTALL_NAME_DIR' option was specified. So this is effectively a removal of dead code with no intended functionality change. The only think we're losing here is that we used to link against libSystem.B.dylib instead of libSystem.dylib when building libc++abi for macOS 10.6 -- however, I strongly suspect nobody's building libc++abi from source for that target anymore. llvm-svn: 373934
* Try to get clangd tests passing on Windows.Nico Weber2019-10-072-10/+10
| | | | | | Part of PR43592. See also r328645. llvm-svn: 373932
* [platform process list] add a flag for showing the processes of all usersWalter Erquinigo2019-10-075-4/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: For context: https://reviews.llvm.org/D68293 We need a way to show all the processes on android regardless of the user id. When you run `platform process list`, you only see the processes with the same user as the user that launched lldb-server. However, it's quite useful to see all the processes, though, and it will lay a foundation for full apk debugging support from lldb. Before: ``` PID PARENT USER TRIPLE NAME ====== ====== ========== ======================== ============================ 3234 1 aarch64-unknown-linux-android adbd 8034 3234 aarch64-unknown-linux-android sh 9096 3234 aarch64-unknown-linux-android sh 9098 9096 aarch64-unknown-linux-android lldb-server (lldb) ^D ``` Now: ``` (lldb) platform process list -x 205 matching processes were found on "remote-android" PID PARENT USER TRIPLE NAME ====== ====== ========== ======================== ============================ 1 0 init 524 1 init 525 1 init 531 1 ueventd 568 1 logd 569 1 aarch64-unknown-linux-android servicemanager 570 1 aarch64-unknown-linux-android hwservicemanager 571 1 aarch64-unknown-linux-android vndservicemanager 577 1 aarch64-unknown-linux-android qseecomd 580 577 aarch64-unknown-linux-android qseecomd ... 23816 979 com.android.providers.calendar 24600 979 com.verizon.mips.services 27888 979 com.hualai 28043 2378 com.android.chrome:sandboxed_process0 31449 979 com.att.shm 31779 979 com.samsung.android.authfw 31846 979 com.samsung.android.server.iris 32014 979 com.samsung.android.MtpApplication 32045 979 com.samsung.InputEventApp ``` Reviewers: labath,xiaobai,aadsm,clayborg Subscribers: llvm-svn: 373931
* [scudo][standalone] Correct releaseToOS behaviorKostya Kortchinsky2019-10-073-27/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: There was an issue in `releaseToOSMaybe`: one of the criteria to decide if we should proceed with the release was wrong. Namely: ``` const uptr N = Sci->Stats.PoppedBlocks - Sci->Stats.PushedBlocks; if (N * BlockSize < PageSize) return; // No chance to release anything. ``` I meant to check if the amount of bytes in the free list was lower than a page, but this actually checks if the amount of **in use** bytes was lower than a page. The correct code is: ``` const uptr BytesInFreeList = Region->AllocatedUser - (Region->Stats.PoppedBlocks - Region->Stats.PushedBlocks) * BlockSize; if (BytesInFreeList < PageSize) return 0; // No chance to release anything. ``` Consequences of the bug: - if a class size has less than a page worth of in-use bytes (allocated or in a cache), reclaiming would not occur, whatever the amount of blocks in the free list; in real world scenarios this is unlikely to happen and be impactful; - if a class size had less than a page worth of free bytes (and enough in-use bytes, etc), then reclaiming would be attempted, with likely no result. This means the reclaiming was overzealous at times. I didn't have a good way to test for this, so I changed the prototype of the function to return the number of bytes released, allowing to get the information needed. The test added fails with the initial criteria. Another issue is that `ReleaseToOsInterval` can actually be 0, meaning we always try to release (side note: it's terrible for performances). so change a `> 0` check to `>= 0`. Additionally, decrease the `CanRelease` threshold to `PageSize / 32`. I still have to make that configurable but I will do it at another time. Finally, rename some variables in `printStats`: I feel like "available" was too ambiguous, so change it to "total". Reviewers: morehouse, hctim, eugenis, vitalybuka, cferris Reviewed By: morehouse Subscribers: delcypher, #sanitizers, llvm-commits Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D68471 llvm-svn: 373930
* Fix Calling Convention through aliasesErich Keane2019-10-074-2/+41
| | | | | | | | | | | | | | r369697 changed the behavior of stripPointerCasts to no longer include aliases. However, the code in CGDeclCXX.cpp's createAtExitStub counted on the looking through aliases to properly set the calling convention of a call. The result of the change was that the calling convention mismatch of the call would be replaced with a llvm.trap, causing a runtime crash. Differential Revision: https://reviews.llvm.org/D68584 llvm-svn: 373929
* [libTooling][NFC] Fix build break in r373916.Yitzhak Mandelbaum2019-10-071-14/+22
| | | | | | r373916 used raw strings inside macro calls, which breaks some builds. llvm-svn: 373928
* [DWARFASTParserClang] Factor out structure-like type parsing, NFCVedant Kumar2019-10-074-432/+473
| | | | | | | | | | | Split out the logic to parse structure-like types into a separate function, in an attempt to reduce the complexity of ParseTypeFromDWARF. Inspired by discussion in https://reviews.llvm.org/D68130. Differential Revision: https://reviews.llvm.org/D68422 llvm-svn: 373927
* [DWARFASTParserClang] Delete commented-out typedef, NFCVedant Kumar2019-10-071-18/+19
| | | | | | (& group together all the protected members & typedefs) llvm-svn: 373926
OpenPOWER on IntegriCloud