This adds some initial support for regions and does not support formatting the specific arguments of a region. For now this can be achieved by using a custom directive that formats the arguments and then parses the region.

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

Symbol names are a special form of StringAttr that get treated specially in certain areas, such as formatting. This revision adds a special derived attr for them in ODS and adds support in the assemblyFormat for formatting them properly.

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

This revision adds support for custom directives to the declarative assembly format. This allows for users to use C++ for printing and parsing subsections of an otherwise declaratively specified format. The custom directive is structured as follows:

```
custom-directive ::= `custom` `<` UserDirective `>` `(` Params `)`
```

`user-directive` is used as a suffix when this directive is used during printing and parsing. When parsing, `parseUserDirective` will be invoked. When printing, `printUserDirective` will be invoked. The first parameter to these methods must be a reference to either the OpAsmParser, or OpAsmPrinter. The type of rest of the parameters is dependent on the `Params` specified in the assembly format.

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

Fixes
C:\src\llvm-project\llvm\docs\CommandGuide\FileCheck.rst:745:Bullet list ends without a blank line; unexpected unindent.

The 1st try was reverted because I missed an assert that
needed softening.

As discussed in D86798 / rG09652721 , we were potentially
returning a different result for whether an Instruction
is commutable depending on if we call the base class or
derived class method.

This requires relaxing asserts in GVN, but that pass
seems to be working otherwise.

NewGVN requires more work because it uses different
code paths for numbering binops and calls.

Reviewed By: efriedma

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

As @nikic is pointing out in https://reviews.llvm.org/rGbf21ce7b908e#inline-4647
this must be sufficient otherwise `EliminateDuplicatePHINodes()`
would have hit issues with it already.

This patch implements the foldMemoryOperand hook in Thumb1InstrInfo,
allowing tBLXr and a spilled function address to be combined back into a
tBL. This can help with codesize at Oz, especailly in the tinycrypt
library.

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

The PE/DLL format has a limit on 64k exported symbols per DLL; make
sure to check this.

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

Summary: Implemented boolean conversion operator for unique_ptr

Reviewers: NoQ, Szelethus, vsavchenko, xazax.hun

Reviewed By: NoQ, xazax.hun

Subscribers: martong, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D86027

fabs and fneg share a common transformation:

(fneg (bitconvert x)) -> (bitconvert (xor x sign))
(fabs (bitconvert x)) -> (bitconvert (and x ~sign))

This patch separate the code into a single method.

Reviewed By: spatel

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

In visitFNEG of DAGCombiner, the folding of (fneg (fsub c, x)) is
redundant since getNegatedExpression already handles it.

Currently replaceBranchTerminator/removeUninterestingBBsFromSwitch
always creates `ret void` instructions if no successor is in the chunk.

This results in invalid IR for functions with non-void return types,
which makes those reductions unfeasible. Instead, create `ret ty undef`
for functions with non-void return types.

Reviewed By: lebedev.ri

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

Shows error produced when trying to return a vector, which is not
yet supported.

Commit `rGf5fd7486` caused a buildbot failure because exceptions are
disabled by default on one of the buildbots. This patch forcibly enables
exceptions for the affected test.

[CodeGen] Make sure the EH cleanup for block captures is conditional when the block literal is in a conditional context

Previously, clang was crashing on the attached test because the EH cleanup for
the block capture was incorrectly emitted under the assumption that the
expression wasn't conditionally evaluated. This was because before 9a52de00260,
pushLifetimeExtendedDestroy was mainly used with C++ automatic lifetime
extension, where a conditionally evaluated expression wasn't possible. Now that
we're using this path for block captures, we need to handle this case.

rdar://66250047

Differential revision: https://reviews.llvm.org/D86854

rdar://67351073

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

Checking the same condition again in a nested `if` usually make no sense,
except if the value of the expression could have been changed between
the two checks. Although compilers may optimize this out, such code is
suspicious: the programmer may have meant to check something else.
Therefore it is worth to find such places in the code and notify the
user about the problem.

This patch implements a basic check for this problem. Currently it
only detects redundant conditions where the condition is a variable of
integral type. It also detects the possible bug if the variable is in an
//or// or //and// logical expression in the inner if and/or the variable
is in an //and// logical expression in the outer if statement. Negated
cases are not handled yet.

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

Finds member initializations in the constructor body which can
be placed to the member initializers of the constructor instead.
This does not only improves the readability of the code but also
affects positively its performance. Class-member assignments
inside a control statement or following the first control
statement are ignored.

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

I tried to fix this in:
rG716e35a0
...but that patch depends on the order that we encounter the
magic "x/sqrt(x)" expression in the combiner's worklist.

This patch should improve that by waiting until we walk the
user list to decide if there's a use to skip.

The AArch64 test reveals another (existing) ordering problem
though - we may try to create an estimate for plain sqrt(x)
before we see that it is part of a 1/sqrt(x) expression.

The change in rG716e35a0 depends on the order that
we encounter the expression x/sqrt(x), so we need to
adjust the logic to be more flexible.

Solves issue https://reviews.llvm.org/D86131#2247275

Reviewed By: hans

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

Summary:
Add support for handling move contructor of std::unique_ptr.

Reviewers: NoQ, Szelethus, vsavchenko, xazax.hun

Reviewed By: NoQ

Subscribers: martong, cfe-commits
Tags: #clang

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

1. Added a dedicated completion to class `CommandObjectTypeFormatterDelete`
   which can be used by these commands: `type filter/format/summary/synthetic delete`;
2. Added a related test case.

Reviewed By: teemperor

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

TestCompletion is randomly failing on some bots. The error message however states
that the computed completions actually do contain the expected pid we're
looking for, so there shouldn't be any test failure.

The reason for that turns out to be that complete_from_to is actually used
for testing two different features. It can be used for testing what the
common prefix for the list of completions is and *also* for checking all the
possible completions that are returned for a command. Which one of the two
things should be checked can't be defined by a parameter to the function, but
is instead guessed by the test method instead based on the results that were
returned. If there is a common prefix in all completions, then that prefix
is searched and otherwise all completions are searched.

For TestCompletion's pid test this behaviour leads to the strange test failures.
If all the pid's that our test LLDB can see have a common prefix (e.g., it
can only see pids [123, 122, 10004, 10000] -> common prefix '1'), then
complete_from_to check that the common prefix contains our pid, which is
always fails ('1' doesn't contain '123' or any other valid pid). If there
isn't a common prefix (e.g., pids are [123, 122, 10004, 777]) then
complete_from_to will check the list of completions instead which works correctly.

This patch is fixing this by adding a simple check method that doesn't
have this behaviour and is simply searching the returned list of completions.
This should get the bots green while I'm working on a proper fix that fixes
complete_from_to.

Imagine we have an archive that has 3 objects in the following order:
<valid known object>,<unknown object> and <valid known object>.

Currently llvm-readelf/obj report an error and stops dumping in the middle.
This patch changes the error reported to warning.

Differential revision: https://reviews.llvm.org/D86771

This reverts commit e9a3d1a4. Seems the new
FileCheck library doesn't link on some bots. Reverting for now.

The actual FileCheck logic seems to be implemented in LLVMSupport. I don't see a
good reason for having FileCheck implemented there as it has a very specific use
while LLVMSupport is a dependency of pretty much every LLVM tool there is. In
fact, the only use of FileCheck I could find (outside the FileCheck tool and the
FileCheck unit test) is a single call in GISelMITest.h.

This moves the FileCheck logic to its own LLVMFileCheck library. This way only
FileCheck and the GlobalISelTests now have a dependency on this code.

Reviewed By: jhenderson

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

Right now all tsan tests are crashing on Linux. The tests were already marked as
expected failures, but since commit 20ce8aff added an assert that every
StopInfo needs a non-empty stop description the tests actually started crash
(which is even with an expectedFailure a failed test).

The reason for that is that we never had any stop description when hitting tsan
errors on Linux. Before the assert that just made the test fail, but now the
empty description is hitting the assert. This patch just adds a generic stop
description mentioning tsan to prevent that we hit that assert on platforms
where we don't support extracting the tsan report.

Reviewed By: friss

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

The Length, AbbrOffset and Values fields of the debug_info section are
optional. This patch helps remove them and simplify test cases.

Reviewed By: MaskRay

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

For an instruction in the basic block BB, SinkingPass enumerates basic blocks
dominated by BB and BB's successors. For each enumerated basic block,
SinkingPass uses `AllUsesDominatedByBlock` to check whether the basic
block dominates all of the instruction's users. This is inefficient.

Use the nearest common dominator of all users to avoid enumerating the
candidate. The nearest common dominator may be in a parent loop which is
not beneficial. In that case, find the ancestors in the dominator tree.

In the case that the instruction has no user, with this change we will
not perform unnecessary move. This causes some amdgpu test changes.

A stage-2 x86-64 clang is a byte identical with this change.