summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* [clangd] Ignore semicolons, whitespace, and comments in SelectionTree.Sam McCall2019-07-314-73/+124
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Whitespace and comments are a clear bugfix: selecting some comments/space near a statement doesn't mean you're selecting the surrounding block. Semicolons are less obvious, but for similar reasons: these tokens aren't actually claimed by any AST node (usually), so an AST-based model like SelectionTree shouldn't take them into account. Callers may still sometimes care about semis of course: - when the selection is an expr with a non-expr parent, selection of the semicolon indicates intent to select the statement. - when a statement with a trailing semi is selected, we need to know its range to ensure it can be removed. SelectionTree may or may not play a role here, but these are separate questions from its core function of describing which AST nodes were selected. The mechanism here is the TokenBuffer from syntax-trees. We use it in a fairly low-level way (just to get boundaries of raw spelled tokens). The actual mapping of AST nodes to coordinates continues to use the (fairly mature) SourceLocation based logic. TokenBuffer/Syntax trees don't currently offer an alternative to getFileRange(), I think. Reviewers: SureYeaah, kadircet Subscribers: MaskRay, jkorous, arphaman, cfe-commits, ilya-biryukov Tags: #clang Differential Revision: https://reviews.llvm.org/D65486 llvm-svn: 367453
* compiler-rt: Rename .cc files in lib/ubsan to .cpp.Nico Weber2019-07-3119-38/+37
| | | | | | | | | | | See https://reviews.llvm.org/D58620 for discussion, and for the commands I ran. In addition I also ran for f in $(svn diff | diffstat | grep .cc | cut -f 2 -d ' '); do rg $f . ; done and manually updated references to renamed files found by that. llvm-svn: 367452
* [MemorySSA] Add additional verification for phis.Alina Sbirlea2019-07-314-1/+75
| | | | | | | | | | | | | | | | | | Summary: Verify that the incoming defs into phis are the last defs from the respective incoming blocks. When moving blocks, insertDef must RenameUses. Adding this verification makes GVNHoist tests fail that uncovered this issue. Reviewers: george.burgess.iv Subscribers: jlebar, Prazek, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63147 llvm-svn: 367451
* gn build: Add build files for compiler-rt/lib/profileNico Weber2019-07-314-4/+75
| | | | | | Differential Revision: https://reviews.llvm.org/D65518 llvm-svn: 367450
* gn build: Make builtin library build on macOSNico Weber2019-07-315-2/+15
| | | | | | | | For now, it only builds the x86_64 slice. Differential Revision: https://reviews.llvm.org/D65513 llvm-svn: 367449
* gn build: Fix redundant object files in builtin lib.Nico Weber2019-07-312-71/+73
| | | | | | | | | | | | | | | | | | | | | | compiler-rt's builtin library has generic implementations of many functions, and then per-arch optimized implementations of some. In the CMake build, both filter_builtin_sources() and an explicit loop at the end of the build file (see D37166) filter out the generic versions if a per-arch file is present. The GN build wasn't doing this filtering. Just do the filtering manually and explicitly, instead of being clever. While here, also remove files from the mingw/arm build that are redundantly listed after D39938 / r318139 (both from the CMake and the GN build). While here, also fix a target_os -> target_cpu typo. Differential Revision: https://reviews.llvm.org/D65512 llvm-svn: 367448
* [InstCombine] canonicalize fneg before fmul/fdivSanjay Patel2019-07-318-101/+116
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reverse the canonicalization of fneg relative to fmul/fdiv. That makes it easier to implement the transforms (and possibly other fneg transforms) in 1 place because we can always start the pattern match from fneg (either the legacy binop or the new unop). There's a secondary practical benefit seen in PR21914 and PR42681: https://bugs.llvm.org/show_bug.cgi?id=21914 https://bugs.llvm.org/show_bug.cgi?id=42681 ...hoisting fneg rather than sinking seems to play nicer with LICM in IR (although this change may expose analysis holes in the other direction). 1. The instcombine test changes show the expected neutral IR diffs from reversing the order. 2. The reassociation tests show that we were missing an optimization opportunity to fold away fneg-of-fneg. My reading of IEEE-754 says that all of these transforms are allowed (regardless of binop/unop fneg version) because: "For all other operations [besides copy/abs/negate/copysign], this standard does not specify the sign bit of a NaN result." In all of these transforms, we always have some other binop (fadd/fsub/fmul/fdiv), so we are free to flip the sign bit of a potential intermediate NaN operand. (If that interpretation is wrong, then we must already have a bug in the existing transforms?) 3. The clang tests shouldn't exist as-is, but that's effectively a revert of rL367149 (the test broke with an extension of the pre-existing fneg canonicalization in rL367146). Differential Revision: https://reviews.llvm.org/D65399 llvm-svn: 367447
* Reland "[DwarfDebug] Dump call site debug info"Djordje Todorovic2019-07-3123-52/+1143
| | | | | | | | | The build failure found after the rL365467 has been resolved. Differential Revision: https://reviews.llvm.org/D60716 llvm-svn: 367446
* [docs][FIX] Add missing word to documentation in terms of SCCsJohannes Doerfert2019-07-311-1/+1
| | | | | | | | In the approval of D65299, commited as rL367440, I mentioned that my proposed wording was lacking the word "maximal". It is added now for correctness. llvm-svn: 367445
* [build] Add the ability to create a symlink for lipoAnusha Basana2019-07-313-0/+11
| | | | | | | | | Add user enabled option to create lipo with symlink to llvm-lipo Used rL326381 for reference. Differential Revision: https://reviews.llvm.org/D65477 llvm-svn: 367444
* [AMDGPU] Fix for vectorizer crash with pointers of different sizeStanislav Mekhanoshin2019-07-312-0/+23
| | | | | | | | | When vectorizer strips pointers it can eventually end up with pointers of two different sizes, then SCEV will crash. Differential Revision: https://reviews.llvm.org/D65480 llvm-svn: 367443
* [Sanitizer][ASAN][MSAN] Fix infinite recursion on FreeBSDAlexander Richardson2019-07-316-11/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: MSAN was broken on FreeBSD by https://reviews.llvm.org/D55703: after this change accesses to the key variable call __tls_get_addr, which is intercepted. The interceptor then calls GetCurrentThread which calls MsanTSDGet which again calls __tls_get_addr, etc... Using the default implementation in the SANITIZER_FREEBSD case fixes MSAN for me. I then applied the same change to ASAN (introduced in https://reviews.llvm.org/D55596) but that did not work yet. In the ASAN case, we get infinite recursion again during initialization, this time because calling pthread_key_create() early on results in infinite recursion. pthread_key_create() calls sysctlbyname() which is intercepted but COMMON_INTERCEPTOR_NOTHING_IS_INITIALIZED returns true, so the interceptor calls internal_sysctlbyname() which then ends up calling the interceptor again. I fixed this issue by using dlsym() to get the libc version of sysctlbyname() instead. This fixes https://llvm.org/PR40761 Reviewers: vitalybuka, krytarowski, devnexen, dim, bsdjhb, #sanitizers, MaskRay Reviewed By: MaskRay Subscribers: MaskRay, emaste, kubamracek, jfb, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D65221 llvm-svn: 367442
* Don't crash when pass by value struct has no definition.Greg Clayton2019-07-311-1/+1
| | | | llvm-svn: 367441
* [docs] Reword documentation in terms of SCCs not cyclesPhilip Reames2019-07-311-8/+15
| | | | | | | | | | | | | | Given the example: header: br i1 %c, label %next, label %header next: br i1 %c2, label %exit, label %header We end up with a loop containing both header and next. Given that, the describing the loop in terms of cycles is confusing since we have multiple distinct cycles within a single Loop. Standardize on the SCC to clarify. Differential Revision: https://reviews.llvm.org/D65299 llvm-svn: 367440
* [NFC][InstCombine] Add xor-or-icmp tests with icmp having extra usesRoman Lebedev2019-07-311-0/+165
| | | | | | | | | | | | | Currently InstCombiner::foldXorOfICmps() bailouts if the ICMP it wants to invert has extra uses. As it can be seen in the tests in previous commit, this is super unfortunate, this is the single pattern that is left non-canonicalized. We could analyze if we can also invert all the uses if said ICMP at the same time, thus not bailing out there. I'm not seeing any nicer alternative. llvm-svn: 367439
* [NFC][InstCombine] Add baseline tests with non-canonical CLAMP patternRoman Lebedev2019-07-311-0/+142
| | | | | | | As disscussed in https://reviews.llvm.org/D65148#1603922 these would all need to be canonicalized to traditional clamp pattern. llvm-svn: 367438
* [AARCH64] Switch relocations R_AARCH64_TLS_TPREL64 and R_AARCH64_DTPMOD64Peter Smith2019-07-313-8/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ELF for the Arm 64-bit Architecture document originally specified R_AARCH64_TLS_DTPREL64 = 0x404 R_AARCH64_TLS_DTPMOD64 = 0x405 LLVM correctly followed the document. Unfortunately in binutils these two codes were reversed: R_AARCH64_TLS_DTPMOD64 = 0x404 R_AARCH64_TLS_DTPREL64 = 0x405 Given that binaries had shipped this change has become the defacto standard interpretation of these relocation codes for any toolchain that wanted to remain compatible with GNU. To recognize this the latest version of the ABI document has renamed the relocations to R_AARCH64_TLS_IMPDEF1 and R_AARCH64_TLS_IMPDEF2 permitting a toolchain to choose between the two relocation types, and recommending that toolchains follow the GNU interpretation for maximum compatibility. Given that upstream llvm has never implemented the standard TLS model for AArch64 so we have no binary legacy, synchronize with GCC so that we don't create incompatible objects in the future. So far the only visible change is in llvm-readobj as it can decode these relocations. Tthis change will mean that llvm-readobj decodes the same way as GNU readelf. fixes PR40507 llvm-svn: 367437
* [X86] Moved IsNOT helper earlier. NFCI.Simon Pilgrim2019-07-311-28/+28
| | | | | | Makes it available for more combines to use without adding declarations. llvm-svn: 367436
* [X86][SSE] Add test cases for PR42825Simon Pilgrim2019-07-311-2/+48
| | | | llvm-svn: 367435
* [ARM] Reject CSEL instructions with invalid operandsMikhail Maltsev2019-07-313-14/+31
| | | | | | | | | | | | | | | | | | | | Summary: According to the Armv8.1-M manual CSEL, CSINC, CSINV and CSNEG are "constrained unpredictable" when SP is used as the source register Rn. The assembler should diagnose this case. Reviewers: momchil.velikov, dmgreen, ostannard, simon_tatham, t.p.northover Reviewed By: ostannard Subscribers: javed.absar, kristof.beyls, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65505 llvm-svn: 367433
* AMDGPU: Add missing builtin declarationsMatt Arsenault2019-07-312-0/+50
| | | | llvm-svn: 367431
* [IPSCCP] Move callsite check to the beginning of the loop.Florian Hahn2019-07-313-15/+122
| | | | | | | | | | | | | | | | | | | | | We have some code marks instructions with struct operands as overdefined, but if the instruction is a call to a function with tracked arguments, this breaks the assumption that the lattice values of all call sites are not overdefined and will be replaced by a constant. This also re-adds the assertion from D65222, with additionally skipping non-callsite uses. This patch should address the cases reported in which the assertion fired. Fixes PR42738. Reviewers: efriedma, davide Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D65439 llvm-svn: 367430
* [X86][AVX] Ensure chained subvector insertions are the same size (PR42833)Simon Pilgrim2019-07-312-9/+13
| | | | | | Before combining insert_subvector(insert_subvector(vec, sub0, c0), sub1, c1) patterns, ensure that the subvectors are all the same type. On AVX512 targets especially we might have a mixture of 128/256 subvector insertions. llvm-svn: 367429
* [AArch64] Add support for Transactional Memory Extension (TME)Momchil Velikov2019-07-3120-13/+326
| | | | | | | | | | | | | | | | | | | | | | | | | Re-commit r366322 after some fixes TME is a future architecture technology, documented in https://developer.arm.com/architectures/cpu-architecture/a-profile/exploration-tools https://developer.arm.com/docs/ddi0601/a More about the future architectures: https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/new-technologies-for-the-arm-a-profile-architecture This patch adds support for the TME instructions TSTART, TTEST, TCOMMIT, and TCANCEL and the target feature/arch extension "tme". It also implements TME builtin functions, defined in ACLE Q2 2019 (https://developer.arm.com/docs/101028/latest) Differential Revision: https://reviews.llvm.org/D64416 Patch by Javed Absar and Momchil Velikov llvm-svn: 367428
* [LLVM] Fix Alignment death tests in Release ModeGuillaume Chatelet2019-07-311-43/+53
| | | | llvm-svn: 367427
* [X86] Regenerate lrshrink test checks to make D65354 diff easierSimon Pilgrim2019-07-311-9/+40
| | | | llvm-svn: 367426
* [X86] Regenerate callee-saved test checks to make D65354 diff easierSimon Pilgrim2019-07-311-23/+33
| | | | llvm-svn: 367425
* [X86] Regenerate alias-static-alloca test checks to make D65354 diff easierSimon Pilgrim2019-07-311-14/+14
| | | | | | I've manually added the stack offsets back as these are worth keeping - we really need a way for update_llc_test_checks.py not to mask out useful address math llvm-svn: 367424
* [DivRemPairs] Fixup DNDEBUG build - variable is only used in assertionRoman Lebedev2019-07-311-0/+1
| | | | llvm-svn: 367423
* gn build: Merge r367393Nico Weber2019-07-311-0/+1
| | | | llvm-svn: 367422
* [X86] Regenerate vp2intersect testsSimon Pilgrim2019-07-311-16/+21
| | | | | | Enable nounwind to remove unnecessary stack manipulation code llvm-svn: 367421
* [lldb][NFC] Check in completion crash test caseRaphael Isemann2019-07-313-0/+18
| | | | llvm-svn: 367420
* [DivRemPairs] Recommit: Handling for expanded-form rem - recomposition (PR42673)Roman Lebedev2019-07-314-22/+118
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: While `-div-rem-pairs` pass can decompose rem in div+rem pair when div-rem pair is unsupported by target, nothing performs the opposite fold. We can't do that in InstCombine or DAGCombine since neither of those has access to TTI. So it makes most sense to teach `-div-rem-pairs` about it. If we matched rem in expanded form, we know we will be able to place div-rem pair next to each other so we won't regress the situation. Also, we shouldn't decompose rem if we matched already-decomposed form. This is surprisingly straight-forward otherwise. The original patch was committed in rL367288 but was reverted in rL367289 because it exposed pre-existing RAUW issues in internal data structures of the pass; those now have been addressed in a previous patch. https://bugs.llvm.org/show_bug.cgi?id=42673 Reviewers: spatel, RKSimon, efriedma, ZaMaZaN4iK, bogner Reviewed By: bogner Subscribers: bogner, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65298 llvm-svn: 367419
* Fix issues with inferior stdout coming out of orderPavel Labath2019-07-314-92/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We've had a bug where two pieces of code, executing on two threads were attempting to write inferior output simultaneously. The first one was in Debugger::HandleProcessEvent, which handled the cases where stdout was coming while the process was running. The second was in CommandInterpreter::IOHandlerInputComplete, which was ensuring that any output is printed before the command which caused process to run terminates. Both of these things make sense, but the fact they were implemented as two independent functions without any synchronization meant that race conditions could occur (e.g. both threads call process->GetSTDOUT, get two chunks of data, but then end up calling stream->Write in opposite order). This was most apparent in situations where a process quickly writes a bunch of output and then exits (as all our register tests do). This patch adds a mutex to ensure that stdout forwarding happens atomically. It also refactors a code somewhat in order to reduce code duplication. Reviewers: clayborg, jingham Subscribers: jfb, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D65152 llvm-svn: 367418
* [DivRemPairs] Avoid RAUW pitfalls (PR42823)Roman Lebedev2019-07-315-56/+121
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: `DivRemPairs` internally creates two maps: * {sign, divident, divisor} -> div instruction * {sign, divident, divisor} -> rem instruction Then it iterates over rem map, and looks if there is an entry in div map with the same key. Then depending on some internal logic it may RAUW rem instruction with something else. But if that rem instruction is an input to other div/rem, then it was used as a key in these maps, so the old value (used in key) is now dandling, because RAUW didn't update those maps. And we can't even RAUW map keys in general, there's `ValueMap`, but we don't have a single `Value` as key... The bug was discovered via D65298, and the test there exists. Now, i'm not sure how to expose this issue in trunk. The bug is clearly there if i change the map keys to be `AssertingVH`/`PoisoningVH`, but i guess this didn't miscompiled anything thus far? I really don't think this is benin without that patch. The fix is actually rather straight-forward - instead of trying to somehow shoe-horn `ValueMap` here (doesn't fit, key isn't just `Value`), or writing a new `ValueMap` with key being a struct of `Value`s, we can just have an intermediate data structure - a vector, each entry containing matching `Div, Rem` pair, and pre-filling it before doing any modifications. This way we won't need to query map after doing RAUW, so no bug is possible. Reviewers: spatel, bogner, RKSimon, craig.topper Reviewed By: spatel Subscribers: hiraditya, hans, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65451 llvm-svn: 367417
* [lldb][NFC] Check in another crashing test caseRaphael Isemann2019-07-313-0/+18
| | | | llvm-svn: 367416
* [DivRemPairs][NFC] Autogenerate all checklinesRoman Lebedev2019-07-314-132/+134
| | | | llvm-svn: 367415
* [ProcessWindows] Choose a register context file by preprocessorTatyana Krasnukha2019-07-315-10/+19
| | | | | | | | | | Replaced Cmake option based check with the preprocessor macro as CMAKE_SYSTEM_PROCESSOR doesn't work as expected on Windows. Fixes llvm.org/pr42724 Differential Revision: https://reviews.llvm.org/D65409 llvm-svn: 367414
* Add llvm-style RTTI to ObjectFile hierarchyPavel Labath2019-07-3120-35/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: On the heels of D62934, this patch uses the same approach to introduce llvm RTTI support to the ObjectFile hierarchy. It also replaces the existing uses of GetPluginName doing run-time type checks with llvm::dyn_cast and friends. This formally introduces new dependencies from some other plugins to ObjectFile plugins. However, I believe this is fine because: - these dependencies were already kind of there, and the only reason we could get away with not modeling them explicitly was because the code was relying on magically knowing what will GetPluginName() return for a particular kind of object files. - the dependencies themselves are logical (it makes sense for SymbolVendorELF to depend on ObjectFileELF), or at least don't actively get in the way (the JitLoaderGDB->MachO thing). - they don't introduce any new dependency loops as ObjectFile plugins don't depend on any other plugins Reviewers: xiaobai, JDevlieghere, espindola Subscribers: emaste, mgorny, arichardson, MaskRay, lldb-commits Differential Revision: https://reviews.llvm.org/D65450 llvm-svn: 367413
* [X86][AVX] Add reduced test case for PR42833Simon Pilgrim2019-07-311-0/+234
| | | | llvm-svn: 367412
* [lldb][NFC] Check in completion crash test in lambdaRaphael Isemann2019-07-313-0/+13
| | | | llvm-svn: 367411
* Add missing includes to SymbolFilePDBTestsPavel Labath2019-07-312-0/+2
| | | | | | These became needed after r367368. llvm-svn: 367410
* Re-disable C4324 MSVC warning that was enabled in D65458 / rL367383Simon Pilgrim2019-07-311-0/+8
| | | | | | This was breaking /WX builds llvm-svn: 367409
* [ARM] Generate MVE VFMAsOliver Cruickshank2019-07-312-0/+391
| | | | llvm-svn: 367408
* [lldb][docs] Add CMake version notes for -B flagStefan Granitz2019-07-312-4/+23
| | | | | | The original documentation update was reviewed with D65330 llvm-svn: 367407
* [Clangd] NFC: Added FIXME in ExtractVariable testsShaurya Gupta2019-07-311-2/+7
| | | | llvm-svn: 367406
* [NFC] Test CommitOliver Cruickshank2019-07-311-2/+2
| | | | llvm-svn: 367405
* Fix mismatching vector type in AlignmentTest.cppGuillaume Chatelet2019-07-311-1/+1
| | | | llvm-svn: 367404
* [RISCV] Support 'f' Inline Assembly ConstraintSam Elliott2019-07-317-0/+120
| | | | | | | | | | | | | | | | | | | | | | | Summary: This adds the 'f' inline assembly constraint, as supported by GCC. An 'f'-constrained operand is passed in a floating point register. Exactly which kind of floating-point register (32-bit or 64-bit) is decided based on the operand type and the available standard extensions (-f and -d, respectively). This patch adds support in both the clang frontend, and LLVM itself. Reviewers: asb, lewis-revill Reviewed By: asb Subscribers: hiraditya, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, s.egerton, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D65500 llvm-svn: 367403
* [NFC][ARMCGP] Use switch in isSupportedValueSam Parker2019-07-311-47/+40
| | | | | | | | Use a switch instead of many isa<> while checking for supported values. Also be explicit about which cast instructions are supported; This allows the removal of SIToFP from GenerateSignBits. llvm-svn: 367402
OpenPOWER on IntegriCloud