This will allow the IncludeCleaner to suppress warnings on the lines with "IWYU
pragma: keep".

Clang APIs are not very convinient, so the code has to navigate around it.

Reviewed By: kadircet

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

This adds a new option `dialectFilter` to BufferizationOptions. Only ops from dialects that are allow-listed in the filter are bufferized. Other ops are left unbufferized. Note: This option requires `allowUnknownOps = true`.

To make use of `dialectFilter`, BufferizationOptions or BufferizationState must be passed to various helper functions.

The purpose of this change is to provide a better infrastructure for partial bufferization, which will be fully activated in a subsequent change.

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

Summary:
The Colours array is apparently the source of TSAN errors. It is
unnecessary and was there to ease readability of the code. Remove it to
clean up the TSAN errors.

Author: Jamie Schmeiser <schmeise@ca.ibm.com>
Reviewed By: aeubanks (Arthur Eubanks)
Differential Revision: https://reviews.llvm.org/D115175

The `default_triple` requirement is redundant if the test specifies the triple, so this patch removes it.

Reviewed By: hubert.reinterpretcast

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

Fix the broken build.

See D114666 for proposed code change to instsimplify.

The difference between the CHECK result of these 2 tests
highlights missed folds in instsimplify
(e.g. (icmp eq (xor X, true), false) -> X) that are
already being handled by instcombine.

The tests are based on:
llvm/test/Transforms/InstSimplify/icmp-bool-constant.ll

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

In addition to being more consistent with our approach for helpers, this
solves an actual issue where <cmath> was using numeric_limits but never
including the <limits> header directly. In a normal setup, this is not
an issue because the <math.h> header included by <cmath> does include
<limits>. However, I did stumble upon some code where that didn't work,
most likely because they were placing their own <math.h> header in front
of ours. I didn't bother investigating further.

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

This patch implements one of the missing builtin functions specified
in https://reviews.llvm.org/D111529.

Test is using "next" commands to make progress in the process. D115137
added an additional statement to the program, without adding a command
to step over it. This only seemed to matter for the libc++ flavour of
the test, possibly because libstdc++ list is "empty" in its
uninitialized state.

Since moving with step commands is a treacherous, this patch adds a
run-to-breakpoint command to the test. It only does this for the
affected step, but one may consider doing it elsewhere too.

Our test infrastructure does not like two tests with the same name, but
it makes sense to do it regardless, as they are testing the same
command.

This patch translates HIP kernels to SPIR-V kernels when the HIP
compilation mode is targeting SPIR-S. This involves:

* Setting Cuda calling convention to CC_OpenCLKernel (which maps to
  SPIR_KERNEL in LLVM IR later on).

* Coercing pointer arguments with default address space (AS) qualifier
  to CrossWorkGroup AS (__global in OpenCL). HIPSPV's device code is
  ultimately SPIR-V for OpenCL execution environment (as
  starter/default) where Generic or Function (OpenCL's private) is not
  supported as storage class for kernel pointer types. This leaves the
  CrossWorkGroup to be the only reasonable choice for HIP buffers.

Reviewed By: yaxunl

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

Qemu normally forwards its (host) environment variables to the emulated
process. While this works fine for most variables, there are some (few, but
fairly important) variables where this is not possible. LD_LIBRARY_PATH
is the probably the most important of those -- we don't want the library
search path for the emulated libraries to interfere with the libraries
that the emulator itself needs.

For this reason, qemu provides a mechanism (QEMU_SET_ENV,
QEMU_UNSET_ENV) to set variables only for the emulated process. This
patch makes use of that functionality to pass any user-provided
variables to the emulated process. Since we're piggy-backing on the
normal lldb environment-handling mechanism, all the usual mechanism to
provide environment (target.env-vars setting, SBLaunchInfo, etc.) work
out-of-the-box, and the only thing we need to do is to properly
construct the qemu environment variables.

This patch also adds a new setting -- target-env-vars, which represents
environment variables which are added (on top of the host environment)
to the default launch environments of all (qemu) targets. The reason for
its existence is to enable the configuration (e.g., from a startup
script) of the default launch environment, before any target is created.
The idea is that this would contain the variables (like the
aforementioned LD_LIBRARY_PATH) common to all targets being debugged on
the given system. The user is, of course, free to customize the
environment for a particular target in the usual manner.

The reason I do not want to use/recommend the "global" version of the
target.env-vars setting for this purpose is that the setting would apply
to all targets, whereas the settings (their values) I have mentioned
would be specific to the given platform.

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

Change to use Ctx.reportError() instead of llvm_unreachable for
better error handling.  Also correct evaluateAsRelocatableImpl().

Reviewed By: simoll

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

Also add tests to check that we print the warning in the right
circumstances.

Reviewed By: labath

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

This patch extends the "is all active predicate" check to cover
cases where the predicate is casted but in a way that doesn't
change its "all active" status.

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

This fixme first appeared in the codebase with the introduction of `ObjectMemoryBuffer` in rG93de2a12, but the constructor appears to never have been templated.

Reviewed By: dexonsmith

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

Some command-line codegen arguments are likely to differ between identical modules discovered from different translation units. This patch removes them to make builds deterministic and/or reduce the number of built modules.

Reviewed By: Bigcheese

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

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

After D113888 / 32b6c17b the MMO size of a masked loads/store is
unknown. When we are converting back to a standard load/store because
the mask is known all ones, we can refine that to the correct size from
the size of the vector being loaded/stored.

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

This patch implements the following:

- Emit PACBTI-M build attributes in libunwind asm files

- Authenticate LR in DWARF32 using PACBTI

Use Armv8.1-M.Main PACBTI extension to authenticate the return address
(stored in the LR register) before moving it to the PC (IP) register.

The AUTG instruction is used with the candidate return address, the CFA,
and the authentication code that is retrieved from the saved
pseudo-register RA_AUTH_CODE.

- Authenticate LR in EHABI using PACBTI

Authenticate the contents of the LR register using Armv8.1-M.Main PACBTI
extension.

A new frame unwinding instruction is introduced (0xb4). This
instruction pops out of the stack the return address authentication
code, which is then used in conjunction with the SP and the next-to-be
instruction pointer to perform authentication.

This authentication code is popped into a new register,
UNW_ARM_PSEUDO_PAC, which is a pseudo-register.

This patch is part of a series that adds support for the PACBTI-M extension of
the Armv8.1-M architecture, as detailed here:

https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/armv8-1-m-pointer-authentication-and-branch-target-identification-extension

The PACBTI-M specification can be found in the Armv8-M Architecture Reference
Manual:

https://developer.arm.com/documentation/ddi0553/latest

The following people contributed to this patch:

- Momchil Velikov
- Victor Campos
- Ties Stuij

Reviewed By: #libunwind, danielkiss, mstorsjo

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

This reverts commit 6de698bf.
It didn't build in the dynamic_hsa configuration

Currently, it is impossible to specify a DataLayout with pointer
size and index size that is not a whole number of bytes.
This patch modifies
the DataLayout class to accept arbitrary pointer sizes and to
store the size as a number of bits, rather than as a number of bytes.
Generally speaking, the external interface of the class as used
by in-tree architectures remains the same and shouldn't affect the
behavior of architecures with pointer sizes equal to a whole number
of bytes.

Note the interface of setPointerAlignment has changed and takes
a pointer and index size that is a number of bits, rather than a number
of bytes.

Patch originally by Ajit Kumar Agarwal

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

These were removed in bda3f2dd but
are needed as it turned out for the MSan tests.

The compiler would judge two concepts is same by their addresses.
However, when we use modules, the addresses wouldn't be the same all the
time since one is parsed in their TU and another is imported in another
TU.
This patch fixes this by using isSameEntity to judge the two concepts.

Reviewed By: rsmith

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

Fails after D110215
with errors like
/usr/include/x86_64-linux-gnu/sys/types.h:33:9: error: unknown type name '__u_char'
typedef __u_char u_char;

Currently, a.k.a printing is closed by default.

Reviewed By: sammccall, kadircet

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

See D115115 and this mailing list discussion:
https://lists.llvm.org/pipermail/llvm-dev/2021-December/154199.html

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

This is a defensive action to catch at build time on Linux failures that
may happen only on Windows otherwise.

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

According to [basic.namespace.general]/p2, a namespace declaration
shouldn't have a module linkage.
> A namespace is never attached to a named module and never has a name
> with module linkage.

Without this patch, the compiler would crash for the test in assertion
enabled build due to inconsistent linkage for redeclaration for
namespaces.

Reviewed by: rsmith

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

According to [module.unit]p7.2.3, a declaration within a linkage-specification
should be attached to the global module.
This let user to forward declare types across modules.

Reviewed by: rsmith, aaron.ballman

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

Add desugared type to hover when the desugared type and the pretty-printed type are different.

```c++
template<typename T>
struct TestHover {
  using Type = T;
};

int main() {
  TestHover<int>::Type a;
}
```

```
variable a

Type: TestHover<int>::Type (aka int)
```

Reviewed By: sammccall

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