The OpenMP target JIT needs testing, so does the IR we actually generate
for the device. This is the initial commit with variations of an "empty
OpenMP kernel" that should all result in a empty IR kernel.

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

AS(4), when targeting GPUs, is constant. Accesses to constant memory are
(historically) not treated as "memory accesses", hence we should deduce
`memory(none)` for those.

This constant was renamed to __riscv_v_fixed_vlen during code
review. I missed this in my search and replace.

We compare this type in the string_test. It had no specialization here
so it could cause linker errors. This patch simply extends the interface
to support it.

Reviewed By: sivachandra

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

GCC emits this warning because the EXPECT_STREQ macro contains an
if-else statement:

  warning: suggest explicit braces to avoid ambiguous ‘else’ [-Wdangling-else]

Update release notes.
This is a follow-up to https://reviews.llvm.org/D146178

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

Add a common predicate for when the `ROR` immediate or "Bitfield
extract, one register" idiom is used for `EXTR` or "Bitfield extract,
two registers".

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

It breaks the logic of maskedVectorize (on tensor.pad ops) into
precondition checks and vectorization implementation; unifies the
interface.

The revision also rename`s vectorizeLinalgOpPrecondition` to
`vectorizeOpPrecondition` because we can vectorize ops other
than LinalgOps.

Reviewed By: dcaballe

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

Addresses the issue found in:
https://lab.llvm.org/buildbot/#/builders/30/builds/35298

The LLVM python bindings are defunct.

They have not seen any substantial active development since 2014.

The version number, which is used to find the libLLVM-NN.so library, has
not been updated since LLVM 10.0 (2019) (and even then they were
probably mostly broken)

After fixing the version number to be able to run them at all, a large
number of tests in the test suite fails.

Already in 2017 the removal was discussed:
 https://discourse.llvm.org/t/is-anyone-using-still-using-the-python-bindings/46063
 https://lists.llvm.org/pipermail/llvm-dev/2017-August/116857.html

There exist external projects providing python bindings for LLVM, e.g:
 https://github.com/numba/llvmlite

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

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

The `SparseTensorType` versions of these methods have some special handling to ensure that they work for unannotated tensors; whereas, the `stt.getEncoding().get{Pos,Crd}Type()` idiom can cause segfaults.

Reviewed By: Peiming

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

Constraint C815 in F'2018 allows a name to acquire an attribute at
most once per scope.  For some attributes, the attribute may have
already been inherited, and the compiler was emitting a bogus error
message for a redundant application of the same attribute in another
scope.

Fixes https://github.com/llvm/llvm-project/issues/60274

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

This patch removes `vector.mask` operations with all-true masks (i.e.,
all lanes enabled).

Reviewed By: hanchung

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

A recent patch enabled this test which turns out to segfault on the
NVPTX architecture. We disable it for now.

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

Don't emit an error message for a possible implicit use of an
external procedure when it is known that the symbol is not
a procedure (e.g., an array).

Fixes https://github.com/llvm/llvm-project/issues/62047

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

Breaks MLIR which happens to be using the intrinsics.

This reverts commit e7b9c2f0.

Let's assumes work for determining no infinities.

These didn't make much sense and we can match the real
pattern.

Presented with "IF (...)" with no following tokens in the statement,
diagnose a missing "THEN" instead of complaining about all of the
possible action statement initial tokens that could have been there
for a non-construct IF statement.

Fixes https://github.com/llvm/llvm-project/issues/62299.

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

We support 0.5.1.

Reviewed By: asb

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

-coverage-notes-file=aaa.gcno -coverage-data-file=bbb.gcda creates aaa.gcno in
the current directory (a pattern to be avoided; which may be read-only in an
alternative lit runner).

Generic matching needs to relax argument compatibility checks when
dummy arguments have !DIR$ IGNORE_TKR directives.

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

The optional argument is needed for CUDA-11+ headers when we're compiling for
sm_80+ GPUs.

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

Modify the prescanner to allow compiler directives to appear in
macro expansions, and adjust the parser to accept a semicolon
as a directive terminator.

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

Value::ValueType is a superset of AddressType. Add a function to
convert an AddressType into a Value::ValueType.

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

[RFC][MC][MachO]Only emits compact-unwind format for "canonical" personality symbols. For the rest, use DWARFs.

Details: https://github.com/rust-lang/rust/issues/102754

The MachO format uses 2 bits to encode these personality funtions, with 0 reserved for "no-personality".
This means we can only have up to 3 personality. There are already three popular personalities:  __gxx_personality_v0, __gcc_personality_v0, and __objc_personality_v0.
As a result, any system that needs custom-personality will run into a problem.

This patch implemented jyknight's proposal to simply force DWARFs for all non-canonical personality functions.

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

[RISCV] Reduce dependency on RISCV::RVVBitsPerBlock for calculating vector size for -mrvv-vector-bits.

We can use the minimum value of the BuiltinType's ElementCount and
the element size.

This needs to be done to support LMUL!=1 types anyway.

I did have to make an ordering change in the error checks in
HandleRISCVRVVVectorBitsTypeAttr to check if the type is an RVV
VLS type before checking the size.

Reviewed By: jhuber6

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

This new functionality will help us avoid duplicated code in various
places in the testing infrastructure. Since the string representation
of the wide numbers is to be used by tests, to keep it simple, we
zero-pad the strings.

Reviewed By: lntue

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

Follow up to "Suppress persistent result when running po" (D144044).

This change delays removal of the persistent result until after `Dump` has been called.
In doing so, the persistent result is available for the purpose of getting its object
description.

In the original change, the persistent result removal happens indirectly, by setting
`EvaluateExpressionOptions::SetSuppressPersistentResult`. In practice this has worked,
however this exposed a latent bug in swift-lldb. The subtlety, and the bug, depend on
when the persisteted result variable is removed.

When the result is removed via `SetSuppressPersistentResult`, it happens within the call
to `Target::EvaluateExpression`. That is, by the time the call returns, the persistent
result is already removed.

The issue occurs shortly thereafter, when `ValueObject::Dump` is called, it cannot make
use of the persistent result variable (instead it uses the `ValueObjectConstResult`). In
swift-lldb, this causes an additional expression evaluation to happen. It first tries an
expression that reference `$R0` etc, but that always fails because `$R0` is removed. The
fallback to this failure does work most of the time, but there's at least one bug
involving imported Clang types.

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

Set the charset to UTF-8, link to the actual liscense we used,
claim support for targets LLVM supports instead of listing them
manually, and stop listing individual language standards we support.