POWER Darwin support in the backend has been removed for some time: https://discourse.llvm.org/t/rfc-remove-darwin-support-from-power-backends
but Clang still has the TargetInfo and other remnants lying around.

This patch does some cleanup and removes those and other related frontend support still remaining. We adjust any tests using the triple to either remove
the test if unneeded or switch to another Power triple.

Reviewed By: MaskRay, nemanjai

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

The test is not applicable because HWASan does not intercept __tls_get_addr.

This is pre-emptive cleanup, to get ready for Kirill's patch to enable sanitizer common tests for HWASan (https://reviews.llvm.org/D147067).

Note that there is an outstanding dynamic TLS bug for sanitizers - https://github.com/google/sanitizers/issues/1409
- but that isn't applicable here due to the lack of interception.

Test: LIT_FILTER=resize_tls_dynamic ninja check-sanitizer

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

the v4 rebuilding is a best-effort because it's not possible to reliably
parse the DWO ID as it requires the abbrev section (& if the index isn't
trustworthy then there's no way to find the associated abbrev section
contribution for a given info section contribution)

But in v5 the DWO ID/type signature is in the header and can be rebuilt
losslessly (only at the cost of performance of rescanning/parsing the
headers of all the units), so let's implement that.

the testing isn't /ideal/ - I think the testing should've been
implemented as a hardcoded dwp file with a corrupted/incorrect index,
then the test could've demonstrated that reparsing the index produces
the right answer - but this is a quick port of the existing v5 test back
to v4 so that we don't lose coverage on the v4 codepath now that it's
separated from the v5 codepath.

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

[clang-tidy] Add option to ignore capture default by reference in cppcoreguidelines-avoid-capture-default-when-capturing-this

The rule exists primarily for when using capture default
by copy "[=]", since member variables will be captured by
reference, which is against developer expectations.

However when the capture default is by reference, then there
is no doubt: everything will be captured by reference. Add
an option to allow just that.

Note: Release Notes do not need update since this check
has been introduced in the current WIP release.

A ticket has been opened at the C++ Core Guidelines repo
to consider updating the rule such that this behavior
is the default one:
https://github.com/isocpp/CppCoreGuidelines/issues/2060

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

This isn't an ideal test - probably would be better if it had a
corrupted index (& was hardcoded - so it didn't depend on llvm-dwp) to
demonstrate that index rebuilding produces a distinct result.

But, ah well, this'll do for now.

Also, handle imaginary numbers, i.e., those with suffixes starting
with an 'i'.

Fixes #61676.

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

Per Fortran 2018, "NAN" and "NAN()" are to be translated into quiet
NaNs, and the other forms are implementation-dependent;  I've made
them quiet NaNs too.  Also process signs on input NaNs, which seems
wrong but other compilers all do it, and fix some misleading template
argument names noticed along the way.

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

FailureOr was used without including correct headers, so the code only works if the user of Transform.h includes the correct headers first.

Reviewed By: jyknight

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

The GPU support for the `libc` generates all its own headers. Since
these headers use the same names as the system headers we need to make
sure that they are separate. Currently, we either use the system headers
on the GPU or the GPU headers on the system. This patch makes them
explicitly separate. A follow-up patch will then make `clang` look in
this folder by default.

Reviewed By: sivachandra, lntue

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

In a now-reverted series of patches, I inadvertently broke the ability
for lldb-server to explain a crash reason. To ensure that this feature
continues to work after future refactors, let's test the feature.

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

Don't check ranks when a pointer actual argument is associated with
a pointer assumed-rank dummy argument.

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

We already use the `amdgpu-arch` and `nvptx-arch` tools to determine the
GPU architectures the user's system supports. We can provide
`LIBC_GPU_ARCHITECTURES=native` to allow users to easily build support
for only the one found on their system. This also cleans up the code
somewhat.

Reviewed By: tra

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

This is a preliminary change to make way for converting the Merger's identifier types from mere typedefs to actual types (which causes some issues that this patch fixes).

Depends On D146676

Reviewed By: aartbik

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

`Function.RawBranchCount` is initialized for fdata profile but not for yaml one.
The diff adds the computation of the field for yaml profiles

Reviewed By: Amir

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

Flang was missing value normalization for logical<->integer conversions
which is required by Flang specification. The shrinking logical<->logical
conversions were also incorrectly truncating the input.
This change performs value normalization for all logical<->integer
conversions and logical<->logical conversions between different kinds.

Note that value normalization is not strictly required for
logical(kind=k1)->logical(kind=k2) conversions when k1 < k2.

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

Missed the default return component of the function on original
implementation, which is a warning that causes subsequent
failure (but regardless it's incorrect behaviour and should
have been fixed).

Currently the cost for fshl is an overestimate causing SLP to vectorize when it is not necessary.

Reviewed By: fhahn

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

Many uses of getIntPtrType() were using that type to calculate the
neened type for GEP offset arguments. However, some time ago,
DataLayout was extended to support pointers where the size of the
pointer is not equal to the size of the values used to index it.

Much code was already migrated to, for example, use getIndexSizeInBits
instead of getPtrSizeInBits, but some rewrites still used
getIntPtrType() to get the type for GEP offsets.

This commit changes uses of getIntPtrType() to getIndexType() where
they are involved in a GEP-related calculation.

In at least one case (bounds check insertion) this resolves a compiler
crash that the new test added here would previously trigger.

This commit does not impact
- C library-related rewriting (memcpy()), which are operating under
the assumption that intptr_t == size_t. While all the mechanisms for
breaking this assumption now exist, doing so is outside the scope of
this commit.
- Code generation ...

Fixes printing of spaces in cases where the following are true:

  1. Persistent results are disabled
  2. The type has a summary string

As reported by @jgorbe in D146783, two spaces were being printed before the summary
string, and no spaces were printed after.

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

The affine loop utility `tilePerfectlyNestedLoops` was checking for the
validity of tiling as well as performing the tiling. This is
inconsistent with how other similar utilities work. Move out the
analysis/check from the utility so that the latter only performs the
mechanics of IR manipulation.

This is NFC/pure move beyond the change in behavior of
tilePerfectlyNestedLoops.

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

LLJIT needs access to symbols (e.g. llvm_orc_registerEHFrameSectionWrapper)
that will be defined in the executable when LLVM is linked statically.

This change is consistent with how other tools within LLVM use LLJIT. It
is required to make sure that `mlir-cpu-runner --host-supports-jit`
correctly returns `true` on platforms that do support JITting (in my
case that's AArch64 Linux).

See https://github.com/llvm/llvm-project/issues/61712 for more context.

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

FEAT_ATS1A adds three new AT system instruction aliases. This feature is
optional from v8.9a/v9.4a. FEAT_ATS1A is a very late addition to the
2022 A-profile VMSA extension, and has not yet been added to the public
docs available on developer.arm.com

These AT instructions are added without a command-line flag or feature,
because it is system-instruction only, and FEAT_S1PIE also has no
command-line flag.

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

[OpenMP][Flang][MLIR] Implement OffloadModuleInterface for OpenMP Dialect and convert is_device to an Attribute

This commit adds the OffloadModuleInterface to the OpenMP dialect,
which will implement future module attribute get/set's for offloading.
Currently it implements set and get's for the omp.is_device attribute,
which is promoted to a real attribute in this commit as well (primarily
to allow switch cases to work nicely with it for future work and to keep
consistency with future module attributes).

This interface is attached to mlir::ModuleOp's on registration of the
OpenMPDialect and should be accessible anywhere the OpenMP
dialect is registered and initialized.

Reviewers: kiranchandramohan, awarzynski

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

Following the steps of the LLVM verifier
(https://github.com/llvm/llvm-project/blob/b2c48559c882fd558f91e471c4d23ea7b0c6e718/llvm/lib/IR/Verifier.cpp#L4195

),
checks in llvm.func verifier are added to ensure consistency of
llvm.landingpad operations' result types and llvm.resume operations'
input types.

As in LLVM, we will allow llvm.resume operations with input values
defined by operations other than llvm.landingpad.

Signed-off-by: Victor Perez <victor.perez@codeplay.com>

Reviewed By: gysit, Dinistro

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

Summary:
These were accidentally added and don't do anything.

This resolves some warnings when building with C++20, e.g.:
```
llvm-project/mlir/lib/Bindings/Python/IRAffine.cpp:545:60: warning: ISO C++20 considers use of overloaded operator '==' (with operand types 'mlir::python::PyAffineExpr' and 'mlir::python::PyAffineExpr') to be ambiguous despite there being a unique best viable function [-Wambiguous-reversed-operator]
                        PyAffineExpr &other) { return self == other; })
                                                      ~~~~ ^  ~~~~~
llvm-project/mlir/lib/Bindings/Python/IRAffine.cpp:350:20: note: ambiguity is between a regular call to this operator and a call with the argument order reversed
bool PyAffineExpr::operator==(const PyAffineExpr &other) {
                   ^
```

Reviewed By: ftynse

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

We had 3 copies of this code, and I am about to add a fourth.

The cost model was not accounting for the fact that we can generate vrgather + an index expression.

Two cases to call out.
1) I did not model the difference between vrgather and vrgatherei16. The result is the constant pool cost can be slightly understated on RV32. I don't think we care, but if someone disagrees, this would be easy to add.
2) Our current codegen for i8 vectors longer than 256 (which is the limit of what this costs) has some room for improvement.

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

Just return the X86::CondCode enum value instead of creating the target constant node in multiple locations, letting us use the getSETCC helper.