Print a single line listing all the categories that are being skipped,
rather than relying on the check.*Support() functions specifying why a
particular category will be skipped. If we know why a category got
skipped, still print that in verbose mode.
The motivation for this change is that sometimes engineers misidentify
the output of these messages as the cause for a test failure (e.g. not
being able to build libc++ or libstdc++).
Differential revision: https://reviews.llvm.org/D100508
When DIE is extracted manually, the DieArray is empty. When dump is invoked on aforementioned DIE it tries to extract child, even if Dump options say otherwise. Resulting in crash.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D99698
Do not hold the free/live thread list lock longer than necessary.
This change speeds up the following benchmark 10x.
constexpr int kTopThreads = 50;
constexpr int kChildThreads = 20;
constexpr int kChildIterations = 8;
void Thread() {
for (int i = 0; i < kChildIterations; ++i) {
std::vector<std::thread> threads;
for (int i = 0; i < kChildThreads; ++i)
threads.emplace_back([](){});
for (auto& t : threads)
t.join();
}
}
int main() {
std::vector<std::thread> threads;
for (int i = 0; i < kTopThreads; ++i)
threads.emplace_back(Thread);
for (auto& t : threads)
t.join();
}
Differential Revision: https://reviews.llvm.org/D100348
This is similar to D83530, but for llvm-objdump.
The motivation is the desire to add an `llvm-otool` symlink to
llvm-objdump that behaves like macOS's `otool`, using the same
technique the at llvm-objcopy uses to behave like `strip` (etc).
This change for the most part preserves behavior. In some cases,
it increases compatibility with GNU objdump a bit. For example,
the long options now require two dashes, and the long options
taking arguments for the most part now require a `=` in front
of the value. Exceptions are flags where tests passed the
value separately, for these the separate form is kept as
an alias to the = form.
The one-letter short form args are now joined or separate
and long longer accept a =, which also matches GNU objdump.
cl::opt<>s in libraries now have to be explicitly plumbed
through. This patch does that for --x86-asm-syntax=, but
there's hope that we can remove that again.
Differential Revision: https://reviews.llvm.org/D100433
Similar to variables with an initializer, this is never valid in
standard C, so we can safely constant-fold as an extension. I ran into
this construct in a couple proprietary codebases.
While I'm here, drive-by fix for 090dd647: we should only fold variables
with VLA types, not arbitrary variably modified types.
Differential Revision: https://reviews.llvm.org/D98363
This reverts commit ab98f2c712 and 98eea392cd.
It includes a fix for the clang test which triggered the revert. I failed to notice this one because there was another AMDGPU llvm test with a similiar name and the exact same text in the error message. Odd. Since only one build bot reported the clang test, I didn't notice that one.
We have seen several crashes in LibCppStdFunctionCallableInfo(...) but we don't have a
reproducer. The last crash pointed to last call to line_entry_helper(...) and symbol
was a nullptr. So adding a check for this case.
We can use the Preprocessor to remap this file, cleaning up the cmake code.
Reviewed By: steveire
Differential Revision: https://reviews.llvm.org/D100343
Breaks check-clang, see comments on D100400
Also revert follow-up "[NFC] Move a recently added utility into a location to enable reuse"
This reverts commit 3ce61fb6d6.
This reverts commit 61a85da882.
We have some cases today where attributes can be inferred from another on access, but the result is not explicitly materialized in IR. This change is a step towards changing that.
Why? Two main reasons:
* Human clarity. It's really confusing trying to figure out why a transform is triggering when the IR doesn't appear to have the required attributes.
* This avoids the need to special case declarations in e.g. functionattrs. Since we can assume the attribute is present, we can work directly from attributes (and only attributes) without also needing to query accessors on Function to avoid missing cases due to unannotated (but infered on use) declarations. (This piece will appear must easier to follow once D100226 also lands.)
Differential Revision: https://reviews.llvm.org/D100400
We are able to config the reducer pass pipeline through command-line.
Reviewed By: jpienaar, rriddle
Differential Revision: https://reviews.llvm.org/D100155
Removes the builtins and intrinsics used to opt in to using these instructions
and replaces them with normal ISel patterns now that they are no longer
prototypes.
Differential Revision: https://reviews.llvm.org/D100402
Add iterator for ReductionNode traversal and use range to indicate the
region we would like to keep. Refactor the interaction between
Pass/Tester/ReductionNode.
Now it'll be easier to add new traversal type and OpReducer
Reviewed By: jpienaar, rriddle
Differential Revision: https://reviews.llvm.org/D99713
Fix the logic of detecting pseudo-virtual getBeginLoc etc on Stmt and
Decl subclasses.
Adjust the test infrastructure to filter out invalid source locations.
This makes the tests more clear about which nodes have which locations.
Differential Revision: https://reviews.llvm.org/D99231
As was done for other locations in commit 54272e5b (NFC:
Replace asserts with if() in SourceLocation accessors, 2019-01-07).
Extracted from https://reviews.llvm.org/D99231
Progress events internally have a completed count and a total count, which can mean that for a job with 20000 total counts, then there will be 20000 events fired. Sending all these events to the IDE can break it. For example, debugging a huge binary resulted in around 50 million messages, which rendered the IDE useless, as it was spending all of its resources simply parsing messages and updating the UI.
A way to fix this is to send unique percentage updates, which are at most 100 per job, which is not much. I was able to debug that big target and confirm that only unique percentage notifications are sent. I can't write a test for this because the current test is flaky. I'll figure out later how to make the test reliable, but fixing this will unblock us from deploy a new version of lldb-vscode.
Differential Revision: https://reviews.llvm.org/D100443
Instead of managing memory by hand, delegate it to std::vector. This makes the
code much simpler, and also avoids repeatedly computing the storage size.
According to valgrind --tool=callgrind, this also slightly decreases the
instruction count, but by a small margin.
Differential Revision: https://reviews.llvm.org/D100387
This reverts commit a32846b1d0.
The build is broken with -DBUILD_SHARED_LIBS=ON:
tools/mlir/lib/Reducer/CMakeFiles/obj.MLIRReduce.dir/Tester.cpp.o: In function `mlir::Tester::isInteresting(mlir::ModuleOp) const':
Tester.cpp:(.text._ZNK4mlir6Tester13isInterestingENS_8ModuleOpE+0xa8): undefined reference to `mlir::OpPrintingFlags::OpPrintingFlags()'
Tester.cpp:(.text._ZNK4mlir6Tester13isInterestingENS_8ModuleOpE+0xc6): undefined reference to `mlir::Operation::print(llvm::raw_ostream&, mlir::OpPrintingFlags)'
It looks like the goal of this code is to provide a more precise
architecture definition for the target when attaching to a process. When
attaching to a foreign debugserver, you might get into a situation where
the active (host) platform will give you bogus information on the target
process.
This change allows the platform to override the target arch only with a
compatible architecture. This fixes TestTargetXMLArch.py on Apple
Silicon. Another alternative would be to just fail in this scenario and
update the test(s).
This functionality is used exactly once, and it is trivial to implement
it differently (capture into two distinct variables, and compare for
equality afterwards).
These were in the shared llgs+platform code, but they only make sense
for llgs (as they deal with how the server reports information about
debugged processes).
Currently, the InstCombineCompare is combining two add operations
into a single add operation which always has a nsw flag, without
checking the conditions to see if this flag should be present
according to the original two add operations or not.
This patch will change the InstCombineCompare to emit the nsw or
nuw only when these flags are allowed to be generated according to
the original add operations and remove the possibility of applying
wrong optimization with passes that will perform on the IR later
in the pipeline.
To confirm that the current results are buggy and the results after
proposed patch are the correct IR the following examples from Alive2
are attached; the same results can be seen in the case of nuw flag
and nsw is just used as an example. The following link shows that
the generated IR with current LLVM is a buggy IR when none of the
original add operations have nsw flag.
https://alive2.llvm.org/ce/z/WGaDrm
The following link proves that the generated IR after the patch in
the former case is the correct IR.
https://alive2.llvm.org/ce/z/wQ7G_e
Differential Revision: https://reviews.llvm.org/D100095
SROA shifts TBAA nodes in a way that may present a problem for !tbaa but not !tbaa.struct nodes.
Differential Revision: https://reviews.llvm.org/D99851
An empty NAME= should mean that there is no C binding, not the
binding that would result from BIND(C) without a NAME=.
See 18.10.2p2.
Differential Revision: https://reviews.llvm.org/D100494
After https://reviews.llvm.org/D90484 libclang is unable to read a serialized diagnostic file
which contains a diagnostic which came from a file with an empty filename. The reason being is
that the serialized diagnostic reader is creating a virtual file for the "" filename, which now
fails after the changes in https://reviews.llvm.org/D90484. This patch restores the previous
behavior in getVirtualFileRef by allowing it to construct a file entry ref with an empty name by
pretending its name is "." so that the directory entry can be created.
Differential Revision: https://reviews.llvm.org/D100428
This makes it clear that headers like <memory> which include auto_ptr
only do that when compiling under an older Standard, or when the removed
feature is explicitly requested.
Jonas Devlieghere