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

This reverts commit 82f0e3d3.

The change breaks the asan buildbots.

https://lab.llvm.org/buildbot/#/builders/99/builds/2835

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

Reapply "[InferAttributes] Materialize all infered attributes for declaration"" and follow on patches.

This reverts commit ab98f2c7 and 98eea392.

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.

This field isn't set in the constructor.
Tweak its accessor to return an ArrayRef.

We can use the Preprocessor to remap this file, cleaning up the cmake code.

Reviewed By: steveire

Differential Revision: https://reviews.llvm.org/D100343

Reviewed By: steveire

Differential Revision: https://reviews.llvm.org/D100378

This reverts commit c609d533.
61a85da8 was reverted in ab98f2c7

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 3ce61fb6.
This reverts commit 61a85da8.

The run method is only called if there is a match with a binding.

An inadvertent ! operator was (fortunately) flagged as a
warning by clang; remove it.

Differential Review: https://reviews.llvm.org/D100513

About to refresh a patch that uses this in FunctionAtrrs, doing the move seperately to control build times.

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

Reviewed By: jpienaar

Differential Revision: https://reviews.llvm.org/D100156

We are able to config the reducer pass pipeline through command-line.

Reviewed By: jpienaar, rriddle

Differential Revision: https://reviews.llvm.org/D100155

This fixes TestGdbRemoteHostInfo on Apple Silicon.

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

Now that 9b8e7a9d ("[lli] Honor the --entry-function flag in orc and
orc-lazy modes") fixed https://llvm.org/PR49906.

Reviewed By: mehdi_amini, aartbik

Differential Revision: https://reviews.llvm.org/D100407

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 a32846b1.

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)'

Differential Revision: https://reviews.llvm.org/D100356

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