- Feb 25, 2021
-
-
Philip Reames authored
-
Joachim Protze authored
Rename a macro and macro use missed in 35ab6d63
-
Jay Foad authored
Update the GlobalISel version of llvm.amdgcn.workitem.id.ll to mostly match the SelctionDAG version. Differential Revision: https://reviews.llvm.org/D97377
-
Joachim Protze authored
When including <ostream>, the register_callback macro of the OMPT callback.h clashes with a function defined in ostream. This patch renames the macro and includes ompt into the macro name.
-
Siva Chandra Reddy authored
-
Louis Dionne authored
-
Louis Dionne authored
-
Eric Schweitz authored
This patch adds the new zero_bits operation and upstrams other changes including the following: - update tablegen syntax to newer forms - update memory effects annotations - update documentation [NFC] - other NFC, such as whitespace and formatting Differential revision: https://reviews.llvm.org/D97331
-
- Feb 24, 2021
-
-
Nathan James authored
Fixes https://bugs.llvm.org/show_bug.cgi?id=38035 Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D96209
-
Eugene Zhulenev authored
Replace math::LogOp with an approximations from the the Julien Pommier's SSE math library Link: http://gruntthepeon.free.fr/ssemath Reviewed By: asaadaldien Differential Revision: https://reviews.llvm.org/D97304
-
Siva Chandra Reddy authored
We want to be able to build and test the string functions in contexts like that of Fuchsia where LLVM pieces like tablegen are not available. Since header generation uses tablegen, we are removing the dependency on headergen here. Reviewed By: gchatelet Differential Revision: https://reviews.llvm.org/D97363
-
Nathan James authored
If a check-suffix is only required for a CHECK-FIXES or CHECK-MESSAGES. check_clang_tidy will pass the prefixes CHECK-FIXES<...> and CHECK-MESSAGES<...> to FileCheck. This will result in a FileCheck failing because of an unused prefix. This addresses the problem by not passing unused prefixes. Its also possible to fix this be passing `--allow-unused-prefixes` flag to FileCheck, but seeing as we have already done the legwork in the script to see its unused, this fix seems the better way to go. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D97322
-
Jinsong Ji authored
We will pass StringRef and change it in reader. But we reuse the same Filename vector without clear it, so in some systems, we may clobbeer previous results. Reviewed By: phosek Differential Revision: https://reviews.llvm.org/D97353
-
Jez Ng authored
-
Sander de Smalen authored
This fixes the types of a few more cost variables to be of type InstructionCost.
-
Nico Weber authored
This reverts commit d3740016. Breaks Analysis/./AnalysisTests/ComputeKnownBitsTest.KnownNonZeroShift
-
Simon Pilgrim authored
This no longer affects any tests after the improvements to the KnownBits shift helpers.
-
Alexander Belyaev authored
https://llvm.discourse.group/t/rfc-add-linalg-tileop/2833 Differential Revision: https://reviews.llvm.org/D97372
-
Raphael Isemann authored
The current API for printing errors/warnings/messages from LLDB commands sometimes adds newlines behind the messages for the caller. However, this happens unconditionally so when the caller already specified a trailing newline in the error message (or is trying to print a generated error message that ends in a newline), LLDB ends up printing both the automatically added newline and the one that was in the error message string. This leads to all the randomly appearing new lines in error such as: ``` (lldb) command a error: 'command alias' requires at least two arguments (lldb) apropos a b error: 'apropos' must be called with exactly one argument. (lldb) why is there an empty line behind the second error? ``` This code adds a check that only appends the new line if the passed message doesn't already contain a trailing new line. Also removes the AppendRawWarning which had only one caller and doesn't serve any purpose now. Reviewed By: #lldb, mib Differential Revision: https://reviews.llvm.org/D96947
-
Jay Foad authored
Add all the registers that are currently used by LLPC: https://github.com/GPUOpen-Drivers/llpc This only affects disassembly of PAL metadata generated by LLPC and similar frontends. Differential Revision: https://reviews.llvm.org/D95619
-
Christian Sigg authored
The cuda-runner registers two pass pipelines for nested passes, so that we don't have to use verbose textual pass pipeline specification. Reviewed By: herhut Differential Revision: https://reviews.llvm.org/D97091
-
Jay Foad authored
Update the list of s_sendmsg messages known to the assembler and disassembler and validate the ones that were added or removed in gfx9 and gfx10. Differential Revision: https://reviews.llvm.org/D97295
-
Raphael Isemann authored
NFC refactoring that moves the definitions of all the trivial getters/setters to the header file which is what we usually do in LLVM. Reviewed By: #lldb, JDevlieghere Differential Revision: https://reviews.llvm.org/D97298
-
Raphael Isemann authored
`ValueObject.h` contains the `ValueObject::ValueObjectManager` type which is just a typedef for the ClusterManager that takes care of the whole ValueObject memory management. However, there is also `ValueObjectManager` defined in the same header which is only used in the curses UI implementation and consists mostly of dead and completely untested code. This code been around since a while (it was added in 2016 as 8369b28d), so I think we shouldn't just revert the whole patch. Instead this patch just moves the class to its own header that it isn't just hiding in the ValueObject header and renames it to `ValueObjectUpdater` that it at least has a unique name (which I hope also slightly better reflects the purpose of this class). I also deleted all the dead code branches and functions. Reviewed By: #lldb, mib, JDevlieghere Differential Revision: https://reviews.llvm.org/D97287
-
Anastasia Stulova authored
When '__cl_clang_function_pointers' extension is enabled the parser should allow obtaining the function address. This fixes PR49264! Differential Revision: https://reviews.llvm.org/D97203
-
Raphael Isemann authored
LLDB tracks where any imported `clang::Decl` originally came from via a simple map from 'imported decl' to 'original decl'. That information is used to later complete parts of the Decl when more information is requested about a certain Decl (e.g., via the ExternalASTSource interface from Clang). When finding the 'original decl' for a given decl, the ASTImporterDelegate essentially just recursively follows the previously mentioned map from 'imported' to 'original decl' until it can find any further 'original decl'. The final found decl is then the one that will be imported. The recursion is necessary as in LLDB we don't just import decls from one ASTContext to another, but also from one ASTContext to another via a (potentially temporary) ASTContext. For example, the expression parser creates a temporary ASTContext for parsing the current expression. The problem with the recursion is however that if we somehow get a cycle into our mapping, then the ASTImporterDelegate will just infinite recurse. As the infinite recursion usually happens after the cycle was already created in a code path such as completing a type, the crash backtraces we get for these bugs are not very useful. However having the backtrace where the faulty map entry is created usually makes the code trivial to fix (as there should be some rogue CopyType call or something similar nearby. See for example D96366). This patch tries to make these issues easier to track down by putting a bunch of sanity asserts in the code that fills out the map. All the asserts are just checking that there is no direct cycle (ASTContext maps to itself) when updating the origin tracking map. The assert in the ASTImportDelegate constructor is an `lldbassert` (which also is getting checked in release builds with disabled asserts) as the code path there is pretty cold and we can reliably detect a rogue CopyType call from there. I also had to update some code in `ClangASTImporter::ASTImporterDelegate::Imported`. This code already had a safety check for creating a cycle in the origin tracking map, but it still constructed an ASTImporter while checking for the cycle (by requesting a delegate via `GetDelegate` and passing two identical ASTContexts which looks like a rogue CopyType call to the checks). Reviewed By: shafik Differential Revision: https://reviews.llvm.org/D97300
-
Simon Pilgrim authored
Followup to D72573 - as detailed in https://blog.regehr.org/archives/1709 we don't make use of the known leading/trailing zeros for shifted values in cases where we don't know the shift amount value. Stop ValueTracking returning zero for poison shift patterns and use the KnownBits shift helpers directly. Extend KnownBits::shl to combine all possible shifted combinations if both min/max shift amount values are in range. Differential Revision: https://reviews.llvm.org/D90479
-
Pierre Gousseau authored
Putting globals in a comdat for dead-stripping changes the semantic and can potentially cause false negative odr violations at link time. If odr indicators are used, we keep the comdat sections, as link time odr violations will be dectected for the odr indicator symbols. This fixes PR 47925
-
Simon Pilgrim authored
-
Lang Hames authored
I'll reinstate and continue investigation tomorrow.
-
Lang Hames authored
-
Lang Hames authored
-
OCHyams authored
If the default target and host triple don't match then print the following message when the lit test runs: Forcing dexter tests to use host triple {HOST_TRIPLE}. If we can't target the host arch then, when lit runs, we mark the dexter test directories as UNSUPPORTED and print the message: Host triple {HOST_TRIPLE} not supported. Skipping dexter tests in the debuginfo-tests project. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D96494 -
Kadir Cetinkaya authored
Differential Revision: https://reviews.llvm.org/D97366
-
Simon Pilgrim authored
As noticed on D97160
-
Lang Hames authored
More experiments as I try to placate sphinx.
-
Lang Hames authored
Also awkwardly reformat text to test whether the error is occurring on the line with the '::', or the previous one.
-
Lang Hames authored
-
Lang Hames authored
Try using the literal domain for `ObjectLinkingLayer::Plugin` and literal blocks for multi-line method names.
-
Florian Hahn authored
This reverts the revert commit 437f0bbc. It adds a new toVPRecipeResult, which forces VPRecipeOrVPValueTy to be constructed with a VPRecipeBase *. This should address ambiguous constructor issues for recipe sub-types that also inherit from VPValue.
-