summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* [LLDB] Add a missing specification of linking against dbghelpMartin Storsjo2019-09-231-0/+8
| | | | | | | | | | | | | | | | | | | The PECOFF object file plugin uses the dbghelp API, but doesn't specify that it has to be linked in anywhere. Current MSVC based builds have probably succeeded, as other parts in LLDB have had a "#pragma comment(lib, "dbghelp.lib")", but there's currently no such pragma in the PECOFF plugin. The "#pragma comment(lib, ...)" approach doesn't work in MinGW mode (unless the compiler is given the -fms-extensions option, and even then, it's only supported by clang/lld, not by GCC/binutils), thus add it to be linked via CMake. (The other parts of LLDB that use dbghelp are within _MSC_VER ifdefs.) Differential Revision: https://reviews.llvm.org/D67885 llvm-svn: 372587
* [LLDB] Use the Windows SOCKET type on all windows targets, not only MSVCMartin Storsjo2019-09-231-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D67859 llvm-svn: 372586
* [Alignment] Get DataLayout::StackAlignment as AlignGuillaume Chatelet2019-09-234-6/+13
| | | | | | | | | | | | | | | | | | | | Summary: Internally it is needed to know if StackAlignment is set but we can expose it as llvm::Align. 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: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67852 llvm-svn: 372585
* Localizer - fix "variable used but never read" analyzer warning. NFCI.Simon Pilgrim2019-09-231-1/+2
| | | | | | Simplify the code by separating the modification of the Changed variable from returning it. llvm-svn: 372583
* TargetInstrInfo::getStackSlotRange - fix "variable used but never read" ↵Simon Pilgrim2019-09-231-1/+1
| | | | | | | | analyzer warning. NFCI. We don't need to divide the BitSize local variable at all. llvm-svn: 372582
* gn build: Merge r372564GN Sync Bot2019-09-231-0/+1
| | | | llvm-svn: 372581
* Revert "Reland "[utils] Implement the llvm-locstats tool""Djordje Todorovic2019-09-237-319/+0
| | | | | | This reverts commit rL372554. llvm-svn: 372580
* [llvm-readobj] - Stop treating ".stack_sizes.*" sections as stack sizes ↵George Rimar2019-09-232-6/+6
| | | | | | | | | | | | | | | | sections. llvm-readobj currently handles .stack_sizes.* (e.g. .stack_sizes.foo) as a normal stack sizes section. Though MC does not produce sections with such names. Also, linkers do not combine .stack_sizes.* into .stack_sizes. A mini discussion about this correctness issue is here: https://reviews.llvm.org/D67757#inline-609274 This patch changes implementation so that only now only '.stack_sizes' name is accepted as a real stack sizes section. Differential revision: https://reviews.llvm.org/D67824 llvm-svn: 372578
* CriticalAntiDepBreaker - Assert that we've found the bottom of the critical ↵Simon Pilgrim2019-09-231-0/+1
| | | | | | | | path. NFCI. Silences static analyzer null dereference warnings. llvm-svn: 372577
* [llvm-readobj] - Implement LLVM-style dumping for .stack_sizes sections.George Rimar2019-09-235-74/+204
| | | | | | | | | D65313 implemented GNU-style dumping (llvm-readelf). This one implements LLVM-style dumping (llvm-readobj). Differential revision: https://reviews.llvm.org/D67834 llvm-svn: 372576
* [NFC] Fixed clang wasm test after rL372573David Bolvansky2019-09-231-2/+2
| | | | | | These tests should not depend on -O1.. llvm-svn: 372575
* [lldb][NFC] Remove unused variable in Options::HandleOptionArgumentCompletionRaphael Isemann2019-09-231-1/+0
| | | | llvm-svn: 372574
* [FunctionAttrs] Enable nonnull arg propagationDavid Bolvansky2019-09-231-4/+1
| | | | | | Enable flag introduced in rL294998. Security concerns are no longer valid, since function signatures for mentioned libc functions has no nonnull attribute (Clang does not generate them? I see no nonnull attr in LLVM IR for these functions) and since rL372091 we carefully annotate the callsites where we know that size is static, non zero. So let's enable this flag again.. llvm-svn: 372573
* [lldb][NFC] Remove dead code in Options::HandleOptionArgumentCompletionRaphael Isemann2019-09-231-9/+2
| | | | llvm-svn: 372572
* [LLD][ELF] - Simplify getFlagsFromEmulation(). NFCI.George Rimar2019-09-231-12/+2
| | | | | | A straightforward simplification. llvm-svn: 372570
* [lldb][NFC] Fix documentation of CompletionRequest::AddCompletionRaphael Isemann2019-09-231-1/+2
| | | | llvm-svn: 372569
* [lldb][NFC] Make cursor char position unsigned in CompletionRequestRaphael Isemann2019-09-232-6/+6
| | | | | | | This was only an 'int' because to fit into the old API which is gone by now. llvm-svn: 372568
* [ARM][MVE] Remove old tail predicatesSam Parker2019-09-236-12/+672
| | | | | | | | | | | Remove any predicate that we replace with a vctp intrinsic, and try to remove their operands too. Also look into the exit block to see if there's any duplicates of the predicates that we've replaced and clone the vctp to be used there instead. Differential Revision: https://reviews.llvm.org/D67709 llvm-svn: 372567
* [lldb] Make cursor index in CompletionRequest unsignedRaphael Isemann2019-09-236-35/+46
| | | | | | | | | | | | The fact that index==-1 means "no arguments" is not obvious and only used in one place from what I can tell. Also fixes several warnings about using the cursor index as if it was a size_t when comparing. Not fully NFC as we now also correctly update the partial argument list when injecting the fake empty argument in the CompletionRequest constructor. llvm-svn: 372566
* [AArch64] support neon_sshl and neon_ushl in performIntrinsicCombine.Florian Hahn2019-09-232-6/+209
| | | | | | | | | | | | | | | | Try to generate ushll/sshll for aarch64_neon_ushl/aarch64_neon_sshl, if their first operand is extended and the second operand is a constant Also adds a few tests marked with FIXME, where we can further increase codegen. Reviewers: t.p.northover, samparker, dmgreen, anemet Reviewed By: anemet Differential Revision: https://reviews.llvm.org/D62308 llvm-svn: 372565
* [ASTImporter][NFC] Add comprehensive tests for ODR violation handling strategiesGabor Marton2019-09-233-184/+671
| | | | | | | | | | | | | | | | | Summary: In this patch we provide additional and comprehensive tests for the ODR handling strategies. This is the continuation of https://reviews.llvm.org/D59692. Reviewers: shafik, a_sidorin, balazske, a.sidorin Subscribers: mgorny, rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66951 llvm-svn: 372564
* [Alignment] fix buildGuillaume Chatelet2019-09-231-5/+6
| | | | llvm-svn: 372562
* [lldb][NFC] Remove argument prefix checking boilerplate when adding completionsRaphael Isemann2019-09-238-30/+64
| | | | llvm-svn: 372561
* [ARM][LowOverheadLoops] Use subs during revert.Sam Parker2019-09-235-27/+47
| | | | | | | | | | Check whether there are any uses or defs between the LoopDec and LoopEnd. If there's not, then we can use a subs to set the cpsr and skip generating a cmp. Differential Revision: https://reviews.llvm.org/D67801 llvm-svn: 372560
* [Alignment][NFC] Switch DataLayout private members to llvm::AlignGuillaume Chatelet2019-09-232-23/+22
| | | | | | | | | | | | | | | | | 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: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67836 llvm-svn: 372558
* [ARM][LowOverheadLoops] Use tBcc when revertingSam Parker2019-09-235-13/+16
| | | | | | | | | Check the branch target ranges and use a tBcc instead of t2Bcc when we can. Differential Revision: https://reviews.llvm.org/D67796 llvm-svn: 372557
* [lldb] Reduce some dangerous boilerplate with CompletionRequest::ShiftArgumentsRaphael Isemann2019-09-235-6/+45
| | | | | | | | | | | | | We should in general not allow external code to fiddle with the internals of CompletionRequest, but until this is gone let's at least provide a utility function that makes this less dangerous. This also now correct updates the partially parsed argument list, but it doesn't seem to be used by anything that is behind one of the current shift/SetCursorIndex calls, so this doesn't seeem to fix any currently used completion. llvm-svn: 372556
* [MIPS GlobalISel] VarArg argument lowering, select G_VASTART and vacopyPetar Avramovic2019-09-2310-6/+588
| | | | | | | | | | | | | | | | CC_Mips doesn't accept vararg functions for O32, so we have to explicitly use CC_Mips_FixedArg. For lowerCall we now properly figure out whether callee function is vararg or not, this has no effect for O32 since we always use CC_Mips_FixedArg. For lower formal arguments we need to copy arguments in register to stack and save pointer to start for argument list into MipsMachineFunction object so that G_VASTART could use it during instruction select. For vacopy we need to copy content from one vreg to another, load and store are used for that purpose. Differential Revision: https://reviews.llvm.org/D67756 llvm-svn: 372555
* Reland "[utils] Implement the llvm-locstats tool"Djordje Todorovic2019-09-237-0/+319
| | | | | | | | | | | | | | | | The tool reports verbose output for the DWARF debug location coverage. The llvm-locstats for each variable or formal parameter DIE computes what percentage from the code section bytes, where it is in scope, it has location description. The line 0 shows the number (and the percentage) of DIEs with no location information, but the line 100 shows the number (and the percentage) of DIEs where there is location information in all code section bytes (where the variable or parameter is in the scope). The line 50..59 shows the number (and the percentage) of DIEs where the location information is in between 50 and 59 percentage of its scope covered. Differential Revision: https://reviews.llvm.org/D66526 llvm-svn: 372554
* [lldb] Fix that importing decls in a TagDecl end up in wrong declaration ↵Raphael Isemann2019-09-232-3/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | context (partly reverts D61333) Summary: In D61333 we dropped some code from ClangASTSource that checks if imported declarations ended up in the right DeclContext. While this code wasn't tested by the test suite (or better, it was hit by the test suite but we didn't have any checks that were affected) and the code seems pointless (as usually Decls should end up in the right DeclContext), it actually broke the data formatters in LLDB and causes a bunch of obscure bugs where structs suddenly miss all their members. The first report we got about this was that printing a std::map doesn't work anymore when simply doing "expr m" (m is the std::map). This patch reverts D61333 partly and reintroduces the check in a more stricter way (we actually check now that we *move* the Decl and it is in a single DeclContext). This should fix all the problems we currently have until we figure out how to properly fix the underlying issues. I changed the order of some std::map formatter tests which is currently the most reliable way to test this problem (it's a tricky setup, see description below). Fixes rdar://55502701 and rdar://55129537 -------------------------------------- Some more explanation what is actually going on and what is going wrong: The situation we have is that if we have a `std::map m` and do a `expr m`, we end up seeing an empty map (even if `m` has elements). The reason for this is that our data formatter sees that std::pair<int, int> has no members. However, `frame var m` works just fine (and fixes all following `expr m` calls). The reason for why `expr` breaks std::map is that we actually copy the std::map nodes in two steps in the three ASTContexts that are involved: The debug information ASTContext (D-AST), the expression ASTContext we created for the current expression (E-AST) and the persistent ASTContext we use for our $variables (P-AST). When doing `expr m` we do a minimal import of `std::map` from D-AST to E-AST just do the type checking/codegen. This copies std::map itself and does a minimal.import of `std::pair<int, int>` (that is, we don't actually import the `first` and `second` members as we don't need them for anything). After the expression is done, we take the expression result and copy it from E-AST to P-AST. This imports the E-AST's `std::pair` into P-AST which still has no `first` and `second` as they are still undeserialized. Once we are in P-AST, the data formatter tries to inspect `std::map` (and also `std::pair` as that's what the elements are) and it asks for the `std::pair` members. We see that `std::pair` has undeserialized members and go to the ExternalASTSource to ask for them. However, P-ASTs ExternalASTSource points to D-AST (and not E-AST, which `std::pair` came from). It can't point to E-AST as that is only temporary and already gone (and also doesn't actually contain all decls we have in P-AST). So we go to D-AST to get the `std::pair` members. The ASTImporter is asked to copy over `std::pair` members and first checks if `std::pair` is already in P-AST. However, it only finds the std::pair we got from E-AST, so it can't use it's map of already imported declarations and does a comparison between the `std::pair` decls we have Because the ASTImporter thinks they are different declarations, it creates a second `std::pair` and fills in the members `first` and `second` into the second `std::pair`. However, the data formatter is looking at the first `std::pair` which still has no members as they are in the other decl. Now we pretend we have no declarations and just print an empty map as a fallback. The hack we had before fixed this issue by moving `first` and `second` to the first declaration which makes the formatters happy as they can now see the members in the DeclContext they are querying. Obviously this is a temporary patch until we get a real fix but I'm not sure what's the best way to fix this. Implementing that the ClassTemplateSpecializationDecl actually understands that the two std::pair's are the same decl fixes the issue, but this doesn't fix the bug for all declarations. My preferred solution would be to complete all declarations in E-AST before they get moved to P-AST (as we anyway have to do this from what I can tell), but that might have unintended side-effects and not sure what's the best way to implement this. Reviewers: friss, martong Reviewed By: martong Subscribers: aprantl, rnkovacs, christof, abidh, JDevlieghere, lldb-commits, shafik Tags: #lldb Differential Revision: https://reviews.llvm.org/D67803 llvm-svn: 372549
* [lldb] Fix LLDB build after r372538Raphael Isemann2019-09-231-1/+2
| | | | llvm-svn: 372548
* Revert "Extension: Mark the default constructor of chrono::duration as ↵Marshall Clow2019-09-232-48/+1
| | | | | | | | conditionally noexcept"; this breaks the gcc5 bot for C++11 This reverts commit c8ca15c95c4c0d6d1356500d5fe49a319ea4ca01. llvm-svn: 372546
* [X86] Canonicalize all zeroes vector to RHS in X86DAGToDAGISel::tryVPTESTM.Craig Topper2019-09-232-24/+19
| | | | llvm-svn: 372544
* [X86] Remove SETEQ/SETNE canonicalization code from LowerIntVSETCC_AVX512 to ↵Craig Topper2019-09-233-9/+29
| | | | | | | | | | | | prevent an infinite loop. The attached test case would previous infinite loop after r365711. I'm going to move this to X86ISelDAGToDAG.cpp to get the setcc to match VPTEST in 32-bit mode in a follow up commit. llvm-svn: 372543
* [X86] Add 32-bit command line to avx512f-vec-test-testn.llCraig Topper2019-09-231-39/+76
| | | | llvm-svn: 372542
* For P0784R7: add further testing of requirements on constexprRichard Smith2019-09-231-0/+68
| | | | | | destructors. llvm-svn: 372541
* Prefer AVX512 memcpy when applicableDavid Zarzycki2019-09-234-90/+259
| | | | | | | | | | | When AVX512 is available and the preferred vector width is 512-bits or more, we should prefer AVX512 for memcpy(). https://bugs.llvm.org/show_bug.cgi?id=43240 https://reviews.llvm.org/D67874 llvm-svn: 372540
* Extension: Mark the default constructor of chrono::duration as conditionally ↵Marshall Clow2019-09-232-1/+48
| | | | | | noexcept llvm-svn: 372539
* For P0784R7: add support for constexpr destructors, and call them asRichard Smith2019-09-2317-159/+741
| | | | | | | | | | | appropriate during constant evaluation. Note that the evaluator is sometimes invoked on incomplete expressions. In such cases, if an object is constructed but we never reach the point where it would be destroyed (and it has non-trivial destruction), we treat the expression as having an unmodeled side-effect. llvm-svn: 372538
* [X86] Convert to Constant arguments to MMX shift by i32 intrinsics to ↵Craig Topper2019-09-232-5/+8
| | | | | | | | | | | | | | TargetConstant during lowering. This allows us to use timm in the isel table which is more consistent with other intrinsics that take an immediate now. We can't declare the intrinsic as taking an ImmArg because we need to match non-constants to the shift by MMX register instruction which we do by mutating the intrinsic id during lowering. llvm-svn: 372537
* [X86] Remove stale FIXME.Craig Topper2019-09-231-1/+0
| | | | | | | This goes back to when MMX was migrated to intrinsic only. The hack referenced here has been gone for quite a while. llvm-svn: 372536
* [X86][SelectionDAGBuilder] Move the hack for handling MMX shift by i32 ↵Craig Topper2019-09-234-86/+79
| | | | | | | | | | | | | | | | | | | | | | intrinsics into the X86 backend. This intrinsics should be shift by immediate, but gcc allows any i32 scalar and clang needs to match that. So we try to detect the non-constant case and move the data from an integer register to an MMX register. Previously this was done by creating a v2i32 build_vector and bitcast in SelectionDAGBuilder. This had to be done early since v2i32 isn't a legal type. The bitcast+build_vector would be DAG combined to X86ISD::MMX_MOVW2D which isel will turn into a GPR->MMX MOVD. This commit just moves the whole thing to lowering and emits the X86ISD::MMX_MOVW2D directly to avoid the illegal type. The test changes just seem to be due to nodes being linearized in a different order. llvm-svn: 372535
* [X86] Require last argument to LWPINS/LWPVAL builtins to be an ICE. Add ↵Craig Topper2019-09-225-12/+32
| | | | | | | | ImmArg to the llvm intrinsics. Update the isel patterns to use timm instead of imm. llvm-svn: 372534
* [NFC] Fixed failed testDavid Bolvansky2019-09-221-1/+1
| | | | llvm-svn: 372533
* [X86] X86DAGToDAGISel::matchBEXTRFromAndImm(): if can't use BEXTR, fallback ↵Roman Lebedev2019-09-222-17/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | to BZHI is profitable (PR43381) Summary: PR43381 notes that while we are good at matching `(X >> C1) & C2` as BEXTR/BEXTRI, we only do that if we either have BEXTRI (TBM), or if BEXTR is marked as being fast (`-mattr=+fast-bextr`). In all other cases we don't match. But that is mainly only true for AMD CPU's. However, for all the CPU's for which we have sched models, the BZHI is always fast (or the sched models are all bad.) So if we decide that it's unprofitable to emit BEXTR/BEXTRI, we should consider falling-back to BZHI if it is available, and follow-up with the shift. While it's really tempting to do something because it's cool it is wise to first think whether it actually makes sense to do. We shouldn't just use BZHI because we can, but only it it is beneficial. In particular, it isn't really worth it if the input is a register, mask is small, or we can fold a load. But it is worth it if the mask does not fit into 32-bits. (careful, i don't know much about intel cpu's, my choice of `-mcpu` may be bad here) Thus we manage to fold a load: https://godbolt.org/z/Er0OQz Or if we'd end up using BZHI anyways because the mask is large: https://godbolt.org/z/dBJ_5h But this isn'r actually profitable in general case, e.g. here we'd increase microop count (the register renaming is free, mca does not model that there it seems) https://godbolt.org/z/k6wFoz Likewise, not worth it if we just get load folding: https://godbolt.org/z/1M1deG https://bugs.llvm.org/show_bug.cgi?id=43381 Reviewers: RKSimon, craig.topper, davezarzycki, spatel Reviewed By: craig.topper, davezarzycki Subscribers: andreadb, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67875 llvm-svn: 372532
* [Diagnostics] Warn if ?: with integer constants always evaluates to trueDavid Bolvansky2019-09-223-0/+77
| | | | | | Extracted from D63082. GCC has this warning under -Wint-in-bool-context, but as noted in the D63082's review, we should put it under TautologicalConstantCompare. llvm-svn: 372531
* [clang] fixing conditional explicit for out-of-line definition PR42980Gauthier Harnisch2019-09-222-4/+22
| | | | | | | | | | | | | | | | Summary: not every read in CXXConstructorDecl::getExplicitSpecifierInternal() was made on the canonical declaration. Reviewers: rsmith, aaron.ballman Reviewed By: rsmith Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67889 llvm-svn: 372530
* Verifier - silence static analyzer dyn_cast<VectorType> null dereference ↵Simon Pilgrim2019-09-221-4/+4
| | | | | | | | warnings. NFCI. The static analyzer is warning about potential null dereferences, but we should be able to use cast<VectorType> directly and if not assert will fire for us. llvm-svn: 372529
* [AMDGPU] isSDNodeAlwaysUniform - silence static analyzer ↵Simon Pilgrim2019-09-221-3/+2
| | | | | | | | dyn_cast<LoadSDNode> null dereference warning. NFCI. The static analyzer is warning about a potential null dereference, but we should be able to use cast<LoadSDNode> directly and if not assert will fire for us. llvm-svn: 372528
* [clang] [Basic] Enable __has_feature(leak_sanitizer)Michal Gorny2019-09-222-0/+13
| | | | | | | | | | Add a 'leak_sanitizer' feature akin to existing '*_sanitizer' features to let programmers switch code paths accounting for leak sanitizers being enabled. Differential Revision: https://reviews.llvm.org/D67719 llvm-svn: 372527
OpenPOWER on IntegriCloud