Pick up the changes from 41b65f16.

In f9fb9da3 we fixed spurious warnings
caused by aliases to private extern symbols. This patch generalizes that
to regular external symbols as well.

The G_ZEXT in these cases seems to actually come from a combine that we do but
SelectionDAG doesn't. Looking through it allows us to match "uxtw #2" addressing
modes.

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

The `Range` of an alias/anchor token includes the leading `&` or `*`,
but it is skipped while parsing the name. The check for an empty name
fails to account for the skipped leading character and so the error is
never hit.

Fix the off-by-one and add a couple regression tests.

Reviewed By: dexonsmith

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

Make sure we can parse and print the user CSR names

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

It's been more than 4 years now, so anyone that was defining
_LIBCPP_TRIVIAL_PAIR_COPY_CTOR has had ample time to see that
error and fix their code.

This reverts commit 105ed27e, and
removes the offending line from the tests.

Add the semantic checks for the OpenMP 4.5 - 2.13.9 Depend clause.

1. List items in depend clause should not be zero length array sections.
2. A variable that is part of another variable like structure component
   should not be specified on a depend clause.

Test cases : omp-depend01.f90, omp-depend02.f90, omp-depend03.f90

Reviewed By: kiranchandramohan

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

We need to make sure the upper 32 bits are all ones to ensure the result is properly sign extended. Previously we only checked the lower 32 bits of the mask. I've also added a check that the shift amount is less than 32. Without that the original code asserts inside maskLeadingOnes if the SROI check is removed or the SROIW pattern is checked first. I've refactored the code to use early outs to reduce nesting.

I've also updated SLOIW matching with the same changes, but I couldn't find a broken test case with the existing code.

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

Regression caused by refactoring in
cdd006ee.

See discussion in https://reviews.llvm.org/D89917.

Reviewed By: arsenm, morehouse

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

Somehow static_assert is a keyword with C on Windows (maybe the Windows
default is C11?). Skipping the test for now.

COMPLEX negation, addition, subtraction, conversions of kind, and
equality/inequality were represented as component-wise REAL
operations.  It turns out to be easier for lowering if we
do not split and recombine these COMPLEX operations, and it
avoids a potential problem with COMPLEX valued function calls
in these contexts.  So add this suite of operations to the
typed expression representation in place of the component-wise
transformations, and support them in folding.

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

Test is failing on non-Windows platforms. Also undo speculative
fix since it causes failures on Windows.

In the existing logic, for a given alloca, as long as its pointer value is stored into another location, it's considered as escaped.
This is a bit too conservative. Specifically, in non-optimized build mode, it's often to have patterns of code that first store an alloca somewhere and then load it right away.
These used should be handled without conservatively marking them escaped.

This patch tracks how the memory location where an alloca pointer is stored into is being used. As long as we only try to load from that location and nothing else, we can still
consider the original alloca not escaping and keep it on the stack instead of putting it on the frame.

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

Speculative fix for failing unittest.

Use the 64-bit SGPR base with a 0 offset, since it's 1 fewer
instruction to materialize the 0 vs. the 64-bit copy.

RegBankSelect would crash on G_SELECT when type is not s1.

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

When the offset doesn't fit in the immediate field, move some to
voffset.

Fix the compilation assertion due to unreachable BB pruning not deleting the associated BB from the jump tables

This patch is added to remove the unreachable MBBs reference in the jump table.

Differential Revisien: https://reviews.llvm.org/D90498
Reviewed by: amyk, bsaleil

The current code allows strided layouts, but the number of elements allocated is ambiguous. It could be either the number of elements in the shape (the current implementation), or the amount of elements required to not index out-of-bounds with the given maps (which would require evaluating the layout map).

If we require the canonical layouts, the two will be the same.

Reviewed By: nicolasvasilache, ftynse

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

This option doesn't enable any unique feature/code-patch. Also, it is
neither tested nor documented.

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

Optimize leaf functions by not generating save/restore for callee saved
registers.  Update regression tests also.

Reviewed By: simoll

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

This adds a simple definition of a "workshare loop" operation for
the OpenMP MLIR dialect, excluding the "reduction" and "allocate"
clauses and without a custom parser and pretty printer.

The schedule clause also does not yet accept the modifiers that are
permitted in OpenMP 5.0.

Co-authored-by: Kiran Chandramohan <kiran.chandramohan@arm.com>

Reviewed By: ftynse, clementval

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

This defines a 'fastcc' for the VE target and implements vreg-to-vreg
copy for parameter passing.  The 'fastcc' extends the standard CC for
SX-Aurora with register passing of vector-typed parameters and return
values.

Reviewed By: kaz7

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

Linux kernel recently added support for kernel modules
  https://lore.kernel.org/bpf/20201110011932.3201430-5-andrii@kernel.org/

In such cases, a type id in the kernel needs to be presented
as (btf id for modules, btf type id for this module).
Change __builtin_btf_type_id() to return 64bit value
so libbpf can do the above encoding.

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

In order to support attribute((constructor)) and attribute((destructor)),
which is used by various LLVM non-C++ runtime components, AIX will include
crti[_64].o and -bcdtors for C language link invocations by default.

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

LLDB is currently always activating C++ when parsing expressions as LLDB itself
is using C++ features when creating the final AST that will be codegen'd
(specifically, references to variables, namespaces and using declarations are
used).

This is causing problems for users that have variables in non-C++ programs (e.g.
plain C or Objective-C) that have names which are keywords in C++. Expressions
referencing those variables fail to parse as LLDB's Clang parser thinks those
identifiers are C++ keywords and not identifiers that may belong to a
declaration.

We can't just disable C++ in the expression parser for those situations as
replacing the functionality of the injected C++ code isn't trivial. So this
patch is just disabling most keywords that are exclusive to C++ in LLDB's Clang
parser when we are in a non-C++ expression. There are a few keywords we can't
disable for now:

* `using` as that's currently used in some situations to inject variables into the expression function.
* `__null` as that's used by LLDB to define `NULL`/`Nil`/`nil`.

Getting rid of these last two keywords is possible but is a large enough change
that this will be handled in follow up patches.

Note that this only changes the keyword status of those tokens but this patch
does not remove any C++ functionality from the expression parser. The type
system still follows C++ rules and so does the rest of the expression parser.

There is another small change that gives the hardcoded macro definitions in LLDB
a higher precedence than the macros imported from the Objective-C modules. The
reason for this is that the Objective-C modules in LLDB are actually parsed in
Objective-C++ mode and they end up providing the C++ definitions of certain
system macros (like `NULL` being defined as `nullptr`). So we have to move the
LLDB definition forward and surround the definition from the module with an
`#ifdef` to make sure that we use the correct LLDB definition that doesn't
reference C++ keywords. Or to give an example, this is how the expression source
code changes:

Before:
```
 #define NULL (nullptr) // injected module definition
 #ifndef NULL
 #define NULL (__null) // hardcoded LLDB definition
 #endif
```

After:
```
 #ifndef NULL
 #define NULL (__null) // hardcoded LLDB definition
 #endif
 #ifndef NULL
 #define NULL (nullptr) // injected module definition
 #endif
```

Fixes rdar://10356912

Reviewed By: shafik

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

This patch adds a new pass to add !annotation metadata for entries in
@llvm.global.anotations, which is generated  using
__attribute__((annotate("_name"))) on functions in Clang.

This has been discussed on llvm-dev as part of
    RFC: Combining Annotation Metadata and Remarks
    http://lists.llvm.org/pipermail/llvm-dev/2020-November/146393.html

Reviewed By: thegameg

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

The logic of vector on boolean was missed. This patch adds the logic and test on
it.

Reviewed By: mravishankar

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

Adapt the declarations of `svpattern` and `svprfop` to the most recent
one defined in section "5. Enum declarations" of the SVE ACLE
specifications [1].

The signature of the intrinsics using these enums have been changed
accordingly.

A test has been added to make sure that `svpattern` and `svprfop` are
not typedefs.

[1] https://developer.arm.com/documentation/100987/latest, version
00bet6

Reviewed By: joechrisellis

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

Add lsv/lvs intrinsic instructions and a regression test.

Reviewed By: simoll

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

Original commit message: "
Move the test compiler setup in a common place. NFCI

This patch reduces the copy paste in the unittest/CodeGen folder by moving the
common compiler setup phase in a header file.

Differential revision: https://reviews.llvm.org/D91061
"

This patch includes a fix for the memory leaks pointed out by @vitalybuka