- Jan 23, 2020
-
-
LLVM GN Syncbot authored
-
Sam Parker authored
Make all the public query methods const.
-
Simon Pilgrim authored
Match the approach in SimplifyDemandedBits where we calculate the demanded elts and then have a common path for the ComputeKnownBits/ComputeNumSignBits call.
-
Fedor Sergeev authored
In case of loops with multiple exit where all-but-one exit are deoptimizing it might happen that the first rotation will end up with latch having a deoptimizing exit. This makes the loop unsuitable for trip-count analysis (say, getLoopEstimatedTripCount) as well as for loop transformations that know how to handle multple deoptimizing exits. It pretty much means that canonical form in multple-deoptimizing-exits case should be with non-deoptimizing exit at latch. Teach loop-rotation to reach this canonical form by repeating rotation. -loop-rotate-multi option introduced to control this behavior, currently disabled by default. Reviewers: skatkov, asbirlea, reames, fhahn Reviewed By: skatkov Tags: #llvm Differential Revision: https://reviews.llvm.org/D73058
-
Guillaume Chatelet authored
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: arsenm, jvesely, nhaehnle, hiraditya, kerbowa, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D73260
-
Krasimir Georgiev authored
Contributed by jbcoe! Summary: Unless SpaceBeforeParensOptions is set to SBPO_Never, a space will be put between `using` and `(` in C# code. Reviewers: klimek, MyDeveloperDay, krasimir Reviewed By: krasimir Subscribers: MyDeveloperDay, cfe-commits Tags: #clang-format, #clang Differential Revision: https://reviews.llvm.org/D72144
-
Kerry McLaughlin authored
Summary: Implements the llvm.aarch64.sve.ldff1 intrinsic and DAG combine rules for first-faulting loads with sign & zero extends Reviewers: sdesmalen, efriedma, andwar, dancgr, rengolin Reviewed By: sdesmalen Subscribers: tschuett, kristof.beyls, hiraditya, rkruppe, psnobl, cameron.mcinally, cfe-commits, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D73025
-
Simon Tatham authored
Summary: Immediate vmvnq is code-generated as a simple vector constant in IR, and left to the backend to recognize that it can be created with an MVE VMVN instruction. The predicated version is represented as a select between the input and the same constant, and I've added a Tablegen isel rule to turn that into a predicated VMVN. (That should be better than the previous VMVN + VPSEL: it's the same number of instructions but now it can fold into an adjacent VPT block.) The unpredicated forms of VBIC and VORR are done by enabling the same isel lowering as for NEON, recognizing appropriate immediates and rewriting them as ARMISD::VBICIMM / ARMISD::VORRIMM SDNodes, which I then instruction-select into the right MVE instructions (now that I've also reworked those instructions to use the same MC operand encoding). In order to do that, I had to promote the Tablegen SDNode instance `NEONvorrImm` to a general `ARMvorrImm` available in MVE as well, and similarly for `NEONvbicImm`. The predicated forms of VBIC and VORR are represented as a vector select between the original input vector and the output of the unpredicated operation. The main convenience of this is that it still lets me use the existing isel lowering for VBICIMM/VORRIMM, and not have to write another copy of the operand encoding translation code. This intrinsic family is the first to use the `imm_simd` system I put into the MveEmitter tablegen backend. So, naturally, it showed up a bug or two (emitting bogus range checks and the like). Fixed those, and added a full set of tests for the permissible immediates in the existing Sema test. Also adjusted the isel pattern for `vmovlb.u8`, which stopped matching because lowering started turning its input into a VBICIMM. Now it recognizes the VBICIMM instead. Reviewers: dmgreen, MarkMurrayARM, miyuki, ostannard Reviewed By: dmgreen Subscribers: kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D72934
-
Simon Tatham authored
Summary: In NEON, the immediate forms of VBIC and VORR are each represented as a single MC instruction, which takes its immediate operand already encoded in a NEON-friendly format: 8 data bits, plus some control bits indicating how to expand them into a full vector. In MVE, we represented immediate VBIC and VORR as four separate MC instructions each, for an 8-bit immediate shifted left by 0, 8, 16 or 24 bits. For each one, the value of the immediate operand is in the 'natural' form, i.e. the numerical value that would actually be BICed or ORRed into each vector lane (and also the same value shown in assembly). For example, MVE_VBICIZ16v4i32 takes an operand such as 0xab0000, which NEON would represent as 0xab | (control bits << 8). The MVE approach is superficially nice (it makes assembly input and output easy, and it's also nice if you're manually constructing immediate VBICs). But it turns out that it's better for isel if we make the NEON and MVE instructions work the same, because the ARMISD::VBICIMM and VORRIMM node types already encode their immediate into the NEON format, so it's easier if we can just use it. Also, this commit reduces the total amount of code rather than increasing it, which is surely an indication that it really is simpler to do it this way! Reviewers: dmgreen, ostannard, miyuki, MarkMurrayARM Reviewed By: dmgreen Subscribers: kristof.beyls, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D73205
-
Miloš Stojanović authored
Since some instruction types aren't allowed as the main instruction also don't allow them for aliasing instructions. Differential Revision: https://reviews.llvm.org/D73220
-
Thomas Preud'homme authored
Summary: This commit adds error checking beyond UndefVarError and fix a number of Error/Expected related idioms: - use (EXPECT|ASSERT)_THAT_(ERROR|EXPECTED) instead of errorToBool or boolean operator - ASSERT when a further check require the check to be successful to give a correct result Reviewers: jhenderson, jdenny, probinson, grimar, arichardson, rnk Reviewed By: jhenderson Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D72914
-
Simon Pilgrim authored
Match the approach in SimplifyDemandedBits/ComputeNumSignBits where we calculate the demanded elts and then have a common path for the ComputeKnownBits call.
-
Simon Pilgrim authored
Match the approach in SimplifyDemandedBits where we calculate the demanded elts and then have a common path for the ComputeKnownBits/ComputeNumSignBits call, additionally we only ever need original demanded elts of the base vector even if the index is unknown.
-
Martin Storsjö authored
-
Djordje Todorovic authored
The low_pc is analog to the DW_AT_call_return_pc, since it describes the return address after the call. The DW_AT_call_pc is the address of the call instruction, and we don't use it at the moment. Differential Revision: https://reviews.llvm.org/D73173
-
Benjamin Kramer authored
The coding standards prefer smaller anonymous namespaces with free functions just being static and in the global namespace.
-
Clement Courbet authored
Summary: ... instead of crashing. On typical exmaple is when there are no available registers. Reviewers: gchatelet Subscribers: tschuett, mstojanovic, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D73196
-
Sam McCall authored
This reverts commit e57a9abc. Parser/cxx2a-placeholder-type-constraint.cpp has MSan failures. Present at 7b81c3f8: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap-msan/builds/17133/steps/check-clang%20msan/logs/stdio not present at eaa594f4: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap-msan/builds/17132/steps/check-clang%20msan/logs/stdio Stack trace: ``` ==57032==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0xccfe016 in clang::AutoTypeLoc::getLocalSourceRange() const /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/include/clang/AST/TypeLoc.h:2036:19 #1 0xcc56758 in CheckDeducedPlaceholderConstraints(clang::Sema&, clang::AutoType const&, clang::AutoTypeLoc, clang::QualType) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Sema/SemaTemplateDeduction.cpp:4505:56 #2 0xcc550ce in clang::Sema::DeduceAutoType(clang::TypeLoc, clang::Expr*&, clang::QualType&, llvm::Optional<unsigned int>, bool) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Sema/SemaTemplateDeduction.cpp:4707:11 #3 0xcc52407 in clang::Sema::DeduceAutoType(clang::TypeSourceInfo*, clang::Expr*&, clang::QualType&, llvm::Optional<unsigned int>, bool) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Sema/SemaTemplateDeduction.cpp:4457:10 #4 0xba38332 in clang::Sema::deduceVarTypeFromInitializer(clang::VarDecl*, clang::DeclarationName, clang::QualType, clang::TypeSourceInfo*, clang::SourceRange, bool, clang::Expr*) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Sema/SemaDecl.cpp:11351:7 #5 0xba3a8a9 in clang::Sema::DeduceVariableDeclarationType(clang::VarDecl*, bool, clang::Expr*) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Sema/SemaDecl.cpp:11385:26 #6 0xba3c520 in clang::Sema::AddInitializerToDecl(clang::Decl*, clang::Expr*, bool) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Sema/SemaDecl.cpp:11725:9 #7 0xb39c498 in clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes(clang::Declarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::ForRangeInit*) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/ParseDecl.cpp:2399:17 #8 0xb394d80 in clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, clang::DeclaratorContext, clang::SourceLocation*, clang::Parser::ForRangeInit*) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/ParseDecl.cpp:2128:21 #9 0xb383bbf in clang::Parser::ParseSimpleDeclaration(clang::DeclaratorContext, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&, bool, clang::Parser::ForRangeInit*, clang::SourceLocation*) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/ParseDecl.cpp:1848:10 #10 0xb383129 in clang::Parser::ParseDeclaration(clang::DeclaratorContext, clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&, clang::SourceLocation*) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/llvm/include/llvm/ADT/PointerUnion.h #11 0xb53a388 in clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector<clang::Stmt*, 32u>&, clang::Parser::ParsedStmtContext, clang::SourceLocation*, clang::Parser::ParsedAttributesWithRange&) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/ParseStmt.cpp:221:13 #12 0xb539309 in clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector<clang::Stmt*, 32u>&, clang::Parser::ParsedStmtContext, clang::SourceLocation*) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/ParseStmt.cpp:106:20 #13 0xb55610e in clang::Parser::ParseCompoundStatementBody(bool) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/ParseStmt.cpp:1079:11 #14 0xb559529 in clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/ParseStmt.cpp:2204:21 #15 0xb33c13e in clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/Parser.cpp:1339:10 #16 0xb394703 in clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, clang::DeclaratorContext, clang::SourceLocation*, clang::Parser::ForRangeInit*) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/ParseDecl.cpp:2068:11 #17 0xb338e52 in clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec&, clang::AccessSpecifier) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/Parser.cpp:1099:10 #18 0xb337674 in clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*, clang::AccessSpecifier) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/Parser.cpp:1115:12 #19 0xb334a96 in clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&, clang::ParsingDeclSpec*) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/Parser.cpp:935:12 #20 0xb32f12a in clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&, bool) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/Parser.cpp:686:12 #21 0xb31e193 in clang::ParseAST(clang::Sema&, bool, bool) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/ParseAST.cpp:158:20 #22 0x80263f0 in clang::FrontendAction::Execute() /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Frontend/FrontendAction.cpp:936:8 #23 0x7f2a257 in clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Frontend/CompilerInstance.cpp:965:33 #24 0x8288bef in clang::ExecuteCompilerInvocation(clang::CompilerInstance*) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:290:25 #25 0xad44c2 in cc1_main(llvm::ArrayRef<char const*>, char const*, void*) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/tools/driver/cc1_main.cpp:239:15 #26 0xacd76a in ExecuteCC1Tool(llvm::ArrayRef<char const*>) /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/tools/driver/driver.cpp:325:12 #27 0xacc9fd in main /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/tools/driver/driver.cpp:398:12 #28 0x7f7d82cdb2e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0) #29 0xa4dde9 in _start (/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm_build_msan/bin/clang-11+0xa4dde9) ```
-
Raphael Isemann authored
This was renamed in 816ae4b0 but it seems the commit only emptied the file instead of deleting it.
-
Russell Gallop authored
Differential Revision: https://reviews.llvm.org/D73162
-
Georgii Rymar authored
We have a `-dyn-symbols` option. It has a `--dyn-syms` alias that is not tested in llvm-readobj tests currently. There was a Object/readobj-elf-versioning.test where it is used, but I've removed it in D73163. And also it is not the right place to test it anyways. Differential revision: https://reviews.llvm.org/D73164
-
Georgii Rymar authored
`readobj-elf-versioning.test` was added in rL152436 and checks how llvm-readobj --dyn-syms prints versioned symbols. We test the same in `llvm-readobj\ELF\dyn-symbols.test` currently. This patch removes the test and 4 more support files from Inputs. Differential revision: https://reviews.llvm.org/D73163
-
Raphael Isemann authored
Summary: This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do (implement the TypeSystem interface for Clang). It also gets rid of the very confusing situation that we have both a `clang::ASTContext` and a `ClangASTContext` in clang (which sometimes causes Clang people to think I'm fiddling with Clang's ASTContext when I'm actually just doing LLDB work). I also have plans to potentially have multiple clang::ASTContext instances associated with one ClangASTContext so the ASTContext naming will then become even more confusing to people. Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere, davide, espindola, jdoerfert, xiaobai Reviewed By: clayborg, labath, xiaobai Subscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay, arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D72684
-
Clement Courbet authored
Summary: Followup to D73161. Reviewers: gchatelet, mstojanovic Subscribers: tschuett, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D73256
-
Markus Böck authored
When annotating a symbol with __declspec(selectany), Clang assigns it comdat 2 while GCC assigns it comdat 3. This patch enables two object files that contain a __declspec(selectany) symbol, one created by gcc and the other by clang, to be linked together instead of issuing a duplicate symbol error. Differential Revision: https://reviews.llvm.org/D73139
-
Daniil Suchkov authored
It is incorrect to call ValueHandleBase::ValueIsRAUWd when only one use is replaced since it simply violates semantics of the callback and leads to bugs like PR44320. Previously this call was used specifically to keep LICM's cache of AliasSetTrackers up to date across passes (as PR36801 showed, even for that purpose it didn't work properly), but since LICM doesn't have that cache anymore, we can safely remove this incorrect call with no repercussions. This patch fixes https://bugs.llvm.org/show_bug.cgi?id=44320 Reviewers: asbirlea, fhahn, efriedma, reames Reviewed-By: asbirlea Differential Revision: https://reviews.llvm.org/D73089
-
Igor Kudrin authored
The padding field is reserved for DWARF and does not contain any useful information. No need to read, store and report it. Differential Revision: https://reviews.llvm.org/D73042
-
Igor Kudrin authored
This structure was used to get the size of the fixed-size part of a Name Index header for 32-bit DWARF. It is unsuitable for 64-bit DWARF because the size of the unit length field is different. Differential Revision: https://reviews.llvm.org/D73040
-
Saar Raz authored
Profile TypeConstraints in ProfileTemplateParameterList so we can distinguish between partial specializations which differ in their TemplateParameterList type constraints. Recommit, now profiling the IDC so that we can deal with situations where the TemplateArgsAsWritten are nullptr (happens when canonicalizing type constraints).
-
Igor Kudrin authored
Differential Revision: https://reviews.llvm.org/D73103
-
Saar Raz authored
Profile TypeConstraints in ProfileTemplateParameterList so we can distinguish between partial specializations which differ in their TemplateParameterList type constraints
-
Martin Storsjö authored
This causes the toplevel "test-depends" target, which should only build all the dependencies necessary for running tests, to suddenaly also run the check-lldb-repro-capture tests. Instead add check-lldb-repro-capture as a dependency to check-lldb-repro with a separate explicit add_dependencies call.
-
Daniil Suchkov authored
-
Daniil Suchkov authored
Apparently cache of AliasSetTrackers held by LICM was the only user of SimpleAnalysis infrastructure. Now, given that we no longer have that cache, this infrastructure is obsolete and, taking into account its nature, we don't want any new solutions to be based on it. Reviewers: asbirlea, fhahn, efriedma, reames Reviewed-By: asbirlea Differential Revision: https://reviews.llvm.org/D73085
-
Igor Kudrin authored
Unfortunately, not all compilers allow using llvm_unreachable in a constexpr function.
-
LLVM GN Syncbot authored
-
Igor Kudrin authored
The patch tries to cover most remaining cases of wrong data. Differential Revision: https://reviews.llvm.org/D71932
-
Igor Kudrin authored
This allows parsing Address Range Tables in the 64-bit DWARF format. Differential Revision: https://reviews.llvm.org/D71876
-
Igor Kudrin authored
This will help simplify code in upcoming patches and make some expressions constexpr. Differential Revision: https://reviews.llvm.org/D73039
-