[flang] Add bind(C) to buitlin C_PTR

D131585 Adds couple of semantics check for the components of BIND(C)
derived-type. This would raise an error when a component is of C_PTR
type. Add `bind(c)` to the `__builtin_c_ptr` type so the wrong error
is not triggered.

Reviewed By: peixin, jeanPerier

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

[libc] Allow construction of const span from mutable span

[ARM] Fix bug in also_compatible_with attribute parser

Check ScopedPrinter pointer before attempting to print the attribute's
parsed information.

Patch by Michael Platings and Victor Campos

Reviewed By: pratlucas

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

[mlir] Fix bots after bytecode support was added in D131747

* Fix ambiguous Twine constructor call
* Ensure shift is 64-bit (for MSVC)
* Disable bytecode tests on s390x (we don't support big endian right now)

[reland][NFC][libc] Use span instead of ArrayRef

Revert "[NFC][libc] Use span instead of ArrayRef"

This reverts commit e7b250b8a6e2bd7e2cb85e0a90d77b1a3326814b.

[NFC][libc] Use span instead of ArrayRef

[mlir] Add initial support for a binary serialization format

This commit adds a new bytecode serialization format for MLIR.
The actual serialization of MLIR to binary is relatively straightforward,
given the very very general structure of MLIR. The underlying basis for
this format is a variable-length encoding for integers, which gets heavily
used for nearly all aspects of the encoding (given that most of the encoding
is just indexing into lists).

The format currently does not provide support for custom attribute/type
serialization, and thus always uses an assembly format fallback. It also
doesn't provide support for resources. These will be added in followups,
the intention for this patch is to provide something that supports the
basic cases, and can be built on top of.

https://discourse.llvm.org/t/rfc-a-binary-serialization-format-for-mlir/63518

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

[SCEV] Prove condition invariance via context, try 2

Initial implementation had too weak requirements to positive/negative
range crossings. Not crossing zero with nuw is not enough for two reasons:

- If ArLHS has negative step, it may turn from positive to negative
  without crossing 0 boundary from left to right (and crossing right to
  left doesn't count for unsigned);
- If ArLHS crosses SINT_MAX boundary, it still turns from positive to
  negative;

In fact we require that ArLHS always stays non-negative or negative,
which an be enforced by the following set of preconditions:

- both nuw and nsw;
- positive step (looks liftable);

Because of positive step, boundary crossing is only possible from left
part to the right part. And because of no-wrap flags, it is guaranteed
to never happen.

[libc] Add a span facility

This is intended to replace ArrayRef.

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

Revert "[clang-format][NFC] Fix a bug in setting type FunctionLBrace"

This reverts commit 35f7dd601d33219fafa2c0d308e187df3e36847a.

Fixes #57200.

[Test] And one more test for PR57247

[clang] Fix warning after D116203

The warning was:
SemaType.cpp:9469:3: error: default label in switch
which covers all enumeration values
[-Werror,-Wcovered-switch-default]

[LoongArch][test] Regenerate loongarch_generated_funcs.test checks

This patch fix test failure due to D132006.

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

[Test] One more test for PR57247

Show that the issue also exists with positive steps.

[RISCV] Add zihintntl instructions

Reviewed By: kito-cheng

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

[LoongArch] Support Load and Store with 14-bit signed immediate operands

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

[libcxx][NFC] utilises compiler builtins for unary transform type-traits

Depends on D116203

Reviewed By: #libc, philnik

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

[clang] adds unary type transformations as compiler built-ins

Adds

* `__add_lvalue_reference`
* `__add_pointer`
* `__add_rvalue_reference`
* `__decay`
* `__make_signed`
* `__make_unsigned`
* `__remove_all_extents`
* `__remove_extent`
* `__remove_const`
* `__remove_volatile`
* `__remove_cv`
* `__remove_pointer`
* `__remove_reference`
* `__remove_cvref`

These are all compiler built-in equivalents of the unary type traits
found in [[meta.trans]][1]. The compiler already has all of the
information it needs to answer these transformations, so we can skip
needing to make partial specialisations in standard library
implementations (we already do this for a lot of the query traits). This
will hopefully improve compile times, as we won't need use as much
memory in such a base part of the standard library.

[1]: http://wg21.link/meta.trans

Co-authored-by: zoecarver
Reviewed By: aaron.ballman, rsmith

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

[PowerPC][Coroutines] Add tail-call check with call information for coroutines

Fixes #56679.

Reviewed By: ChuanqiXu, shchenz

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

[AArch64][NFC] Replace setOperationAction and AddPromotedToType
with setOperationPromotedToType.

Reviewed By: dmgreen

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

[sanitizer] use ../runtimes path to build libcxx

[clang-format] Fix BeforeHash indent of comments above PPDirective

Fixes #56326.

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

[ADT] Remove `is_invocable` from `STLExtras.h`

As a follow-up of https://reviews.llvm.org/D132318, now that the callers have
been adjusted to use `std::is_invocable`, remove `llvm::is_invocable` and its
tests.

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

[ADT] Clarify llvm::bit_cast implementation comment

When reviewing https://reviews.llvm.org/D132330, I noticed a few pre-existing
comments regarding the implementation of `llvm::bit_cast`. One comment is a bit
misleading since `std::bit_cast` is a C++20 standard library thing, not a
C++17 one (otherwise we could use it directly). Clarify that in the comment.

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

[RISCV] Remove impossible TODO in RISCVRedundantCopyElimination. NFC

If there are multiple conditional branches we shouldn't do any
optimization.

[RISCV] Optimize x <s -1 ? x : -1. Improve x >u 1 ? x : 1.

Similar to D132211, we can optimize x <s -1 ? x : -1 -> x <s 0 ? x : -1

Also improve the unsigned case from D132211 to use x != 0 which
will give a bnez instruction which might be compressible.

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

[RISCV] Be more strict about LUI+ADDI macrofusion pre-RA.

Don't macrofuse if the LUI has more than 1 user. That will likely
require the LUI to have a different destination register post-RA.
LUI+ADDI can only be fused if they write the same register.

[ADT] Simplify llvm::bit_cast (NFC)

This patch removes macro tricks to check GCC versions.

The commit message from 19262fc5966ab569f21f3d440f8b001bca666f17
states that "is_trivially_copyable is only in GCC 5.1 and later".
Note that we now require GCC 7.1 or higher.

Since both std::is_trivially_constructible and
std::is_trivially_copyable are C++11 features, and we now require
C++17, we probably don't need to worry about the availability of the
C++11 features.

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

Remove llvm::is_trivially_copyable (NFC)

This patch removes llvm::is_trivially_copyable as it seems to be dead.
Once I remove it, HAVE_STD_IS_TRIVIALLY_COPYABLE has no users, so this
patch removes the macro also.

The comment on llvm::is_trivially_copyable mentions GCC 4.9, but note
that we now require GCC 7.1 or higher.

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

[flang][OpenMP] Parser support for Target directive and Device clause

This patch adds support for the device clause on `Target` directive.
Device clause was added in OpenMP specification version 4.5 to
create a device data environment for the extent of a region. On
target construct, the device expression be either be `ancestor`
(taking after the parent) or assign a new `device_num`.

Reviewed By: kiranchandramohan

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

[CostModel][X86] Add CodeSize handling for fadd/fsub/fmul/fsqrt ops

Eventually this will be part of the cost table lookup

[ADT] Replace `void_t` equivalent with `std::void_t`

Use `std::void_t` instead of defining our own equivalent in `STLExtras.h` now
that C++17 is available for use.

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

Revert rG15de7aaae52ef4be9f9ff3b130804e5b5ccd29f4 "[CostModel][X86] Add CodeSize/SizeLatency handling for fadd/fsub/fmul/fsqrt ops"

This is unintentionally affecting some backend tests

[CostModel][X86] Add CodeSize/SizeLatency handling for fadd/fsub/fmul/fsqrt ops

Eventually this will be part of the cost table lookup

[NFC][libc++][doc] Improves rst formatting.

[NFC][mlir][affine] Typo in Affine Analysis test

Reviewed By: Groverkss

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

[libc++] Fix typos in deprecation messages for experimental searchers

Fix the typo in the deprecated messages for these searchers:
`s/exprerimental/experimental`.

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

[InstCombine] reassociate bitwise logic chains based on uses

(X op Y) op Z --> (Y op Z) op X

This isn't a complete solution (see TODO tests for possible refinements),
but it shows some nice wins and doesn't seem to cause any harm. I think
the most potential danger is from conflicting with other folds and causing
an infinite loop - that's the reason for avoiding patterns with constant
operands.

Alternatively, we could try this in the reassociate pass, but we would not
immediately see all of the logic folds that instcombine provides. I also
looked at improving ValueTracking's isImpliedCondition() (and we should
still add some enhancements there), but that would not work in general for
bitwise logic reduction.

The tests that reduce completely to 0/-1 are motivated by issue #56653.

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

[CMake] Weaken 176db3b3ab25ff8a9b2405f50ef5a8bd9304a6d5

That commit (D132324) made putting libc++ in LLVM_ENABLE_RUNTIMES a hard
error, but ther are some out-of-tree CI jobs (especially docs that need
fixing).

I am thus making it a "soft error" for now, until that is resolved.

[PhaseOrdering][X86] Regenerate vdiv.ll

Noticed while cleaning up x86 cost tables for upcoming cost kind support and it affected this test

[RISCV] Optimize x > 1 ? x : 1 -> x > 0 ? x : 1

if x == 1,
  x > 1 ? x : 1  return x, which is also 1.
  x > 0 ? x : 1  return 1.

Reduce the number of load 1 instructions.

Reviewed By: craig.topper

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

[libcxxabi][cmake] Allow building without libcxx again

This allows `-DLLVM_ENABLE_RUNTIMES=libcxxabi` to work.

This functionality was removed in D125561 (among other such removals) as
dead code, because it was only available as part of the standalone build
before.

The functionality as added back as it was, except `target_include_directories` is used instead of the cruder `target_compile_options` (with an MSVC vs not MSVC conditional split). That is just wholly better.

Reviewed By: phosek, #libc_abi

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

[RFC] Remove support for building C++ with `LLVM_ENABLE_PROJECTS`

This has been officially deprecated since D112724, meaning the
deprecation warning is present in released 14 and 15.

This makes me think that now, shortly after the 15 release is branched,
is a good time to pull the trigger.

Reviewed By: phosek

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

[CostModel][X86] Add trunc cost kinds tests

[CostModel][X86] Split integer div/rem cost kinds tests

It's going to be much easier to maintain these tests (and all the check prefix combinations) if we don't mix cost kinds in the same file.

[Orc] Improve deintialize and shutdown logic

When deinitializing, the allocation needs to be removed from the
allocation list of its associated reservation so that remaining
allocations can be deinitialized when releasing the reservation.

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

[Orc] Provide correct Reservation address for slab allocations

When slab allocator is used, the MappingBase is not necessarily
the same as the original reservation base as the allocation could
be a part of the whole reservation.

In this case the original reservation address needs to be passed to
ExecutorSharedMemoryMapperService to associate the new allocation
with the original reservation.

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

[Orc] Only unmap shared memory in controller process destructor

By the time SharedMemoryMapper destructor is called, the RPC
connection is no longer available causing the release() call to
always fail. Instead at this point only shared memory regions
can be unmapped safely.

Deinitializers are called and mapped memory is released at the
executor side by ExecutorSharedMemoryMapperService::shutdown()
instead. Memory can also be released earlier by calling release()
earlier before RPC connection is closed.

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

[Orc] Actually save the callback

The callback function was captured by reference but it lived on the
stack and was in danger of being overwritten and could cause a crash.

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

[CostModel][X86] Split int/fp arithmetic cost kinds tests

It's going to be much easier to maintain these tests (and all the check prefix combinations) if we don't mix cost kinds in the same file.

[mlir][normalize-memrefs] NFC Follow-up D125854

NFC follow-up D125854 to reflect some remaining comments in D125854

Reviewed By: bondhugula

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

[CostModel] Add CostKind argument to getShuffleCost

Defaults to TCK_RecipThroughput - as most explicit calls were assuming TCK_RecipThroughput (vectorizers) or was just doing a before-vs-after comparison (vectorcombiner). Calls via getInstructionCost were just dropping the CostKind, so again there should be no change at this time (as getShuffleCost and its expansions don't use CostKind yet) - but it will make it easier for us to better account for size/latency shuffle costs in inline/unroll passes in the future.

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

[C++20][Modules] Improve handing of Private Module Fragment diagnostics.

This adds a check for exported inline functions, that there is a definition in
the definition domain (which, in practice, can only be the module purview but
before any PMF starts) since the PMF definition domain cannot contain exports.

This is:
[dcl.inline]/7
If an inline function or variable that is attached to a named module is declared in
a definition domain, it shall be defined in that domain.

The patch also amends diagnostic output by excluding the PMF sub-module from the
set considered as sources of missing decls.  There is no point in telling the user
that the import of a PMF object is missing - since such objects are never reachable
to an importer.  We still show the definition (as unreachable), to help point out
this.

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

[mlir][Bazel] Fix Bazel build

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

Revert "Use std::is_same_v instead of std::is_same (NFC)"

This reverts commit c5da37e42d388947a40654b7011f2a820ec51601.

This patch seems to break builds with some versions of MSVC.

Use std::is_same_v instead of std::is_same (NFC)

Use range-based for loops (NFC)

Use llvm::drop_begin (NFC)

Remove redundant initialization of Optional (NFC)

Use llvm::is_contained (NFC)

[Scalar] Qualify auto in range-based for loops (NFC)

Identified with readability-qualified-auto.

Ensure newlines at the end of files (NFC)

[libunwind] Fixed a number of typos

I went over the output of the following mess of a command:

`(ulimit -m 2000000; ulimit -v 2000000; git ls-files -z | parallel --xargs -0 cat | aspell list --mode=none --ignore-case | grep -E '^[A-Za-z][a-z]*$' | sort | uniq -c | sort -n | grep -vE '.{25}' | aspell pipe -W3 | grep : | cut -d' ' -f2 | less)`

and proceeded to spend a few days looking at it to find probable typos
and fixed a few hundred of them in all of the llvm project (note, the
ones I found are not anywhere near all of them, but it seems like a
good start).

Reviewed By: #libunwind, MaskRay

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

[mlir] Use std::is_invocable instead of llvm::is_invocable

Now that MLIR is built with C++17, use the standard library equivalent of
`llvm::is_invocable`: `std::is_invocable`.

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

[llvm] Remove llvm::is_trivially_{copy/move}_constructible (NFC)

This patch removes llvm::is_trivially_{copy/move}_constructible in
favor of std::is_trivially_{copy/move}_constructible.

The previous attempt to remove them in Dec 2020,
c8d406c93c5bb01599990201f78d8428dd29d289, broke builds with "some
versions of GCC" according to
6cd9608fb37ca2418fb44b57ec955bb5efe10689.

It's been 20 months since then, and the minimum requirement for GCC
has been updated to 7.1 from 5.1.

FWIW, I was able to build llvm with gcc 8.4.0.

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

[JITLink] Fix LinkGraph::makeAbsolute, add unit test.

makeAbsolute was not updating the symbol address when applied to external
symbols.

This commit adds a unit test for makeAbsolute, and updates the makeExternal unit
test to check that makeExternal works correctly for absolute symbols.

[libc++][string] Removes obsolete constexpr.

Addresses the final review comment of D131421.

Reviewed By: philnik, #libc

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

[gn build] Fix oversight in 3adda398cef7f56d0

[bolt][llvm][cmake] Use `CMAKE_INSTALL_LIBDIR` too

Working back towards D130586.

Bolt didn't use `LLVM_LIBDIR_SUFFIX` before, and has no in-tree reverse
dependencies, it seems easier to add.

The change in LLVM itself is to prevent some unexpected `lib64` from
cropping up due to the `CMAKE_INSTALL_LIBDIR` defaulting logic.

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

[clang][lldb][cmake] Use new `*_INSTALL_LIBDIR_BASENAME` CPP macro

Use this instead of `*_LIBDIR_SUFFIX`, from which it is computed.

This gets us ready for D130586, in which `*_LIBDIR_SUFFIX` is
deprecated.

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

[ADT] Simplify llvm::sort with constexpr if (NFC)

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

[ADT] Deprecate Any::hasValue

This patch deprecates Any::hasValue as I've migrated all known uses of
it to Any::has_value.  I'm planning to remove the deprecated method in
3 months or so.

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

[clang] Use Any::has_value instead of Any::hasValue (NFC)

[flang] Add semantic checks for interoperability of derived type (C1806)

As Fortran 2018 C1806, each component of a derived type with the BIND
attribute shall be a nonpointer, nonallocatable data component with
interoperable type.

Reviewed By: klausler

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

[flang][OpenMP] Handle the data race for firstprivate and lastprivate

Remove barriers for firstprivate except if the variable is also
lastprivatized. Re-arrange code and put all last-privates inside a
single scf.if.

As OpenMP Spec 5.0, to avoid the data races, concurrent updates of the
original list item must be synchronized with the read of the original
list item that occurs as a result of the firstprivate clause. Adding
barrier(s) before and/or after the worksharing region would remove the
data races, and it is the application(user)'s job. However, when
one list item is in both firstprivate and lastprivate clauses, the
standard (https://www.openmp.org/spec-html/5.0/openmpsu105.html) states
the following:
```
If a list item appears in both firstprivate and lastprivate clauses, the
update required for the lastprivate clause occurs after all
initializations for the firstprivate clause.
```

So, the synchronization should be ensured by compiler such as emiting
one barrier since the lastprivate clause follows the reads of the
original list item performed for the initialization of each of the
firstprivate list item.

Add FIXME for two special cases, sections construct and linear clause.

The data race problem for single construct will be handled later.

This implementation is based on the discussion with OpenMP committee and
clang code (clang/lib/CodeGen/CGStmtOpenMP.cpp).

Reviewed By: kiranchandramohan, NimishMishra

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

[lldb] Use Any::has_value instead of ANy::hasValue (NFC)

[ADT] Implement Any::has_value

This patch implements Any::has_value for consistency with std::any in
C++17.

My plan is to deprecate Any::hasValue after migrating all of its uses
to Any::has_value.  Since I am about to do so, this patch simply
replaces hasValue with has_value in the unit test instead of adding
tests for has_value.

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

[ADT] Simplify llvm::reverse with constexpr if (NFC)

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

[EarlyCSE][ConstantFolding] do not constant fold atan2(+/-0.0, +/-0.0), part 2

Follow-up to 7f1262a322c0d80f3. That patch avoided removing the
call, but it still allowed the constant-folded result. This
makes the behavior consistent with 1-arg libm folding: if the
call potentially raises an exception, then we just bail out.

It seems likely that there are other corner-cases like this,
but the tests are incomplete, so we have lived with these
discrepancies for a long time. This was untested before the
the constant folding was expanded in D127964.

[X86] Fold PMULUDQ(X,1) -> AND(X,(1<<32)-1) 'getZeroExtendInReg'

Fix cases where shl/srem/urem expansion results in a mulh/mul_lohi(x,1) 'pass through' that gets lowered to pmuludq.

Fixes #56684

[X86] Add vector test coverage of 'one-bit-diff' and/or icmp ne/eq patterns

[libc++][doc] Updates status of P2291R3.

Work on the paper has started but it's blocked by PR52954.
Updating the status to avoid duplicated effort implementing this paper.

More llvm-docs-sphinx buildbot fixes

Broken by 7225c0bd0115c947f3c081599e6268cfa027722f and
662a11bd062ac7d938569212fe1c5dc01c1a1b34.

Fix llvm-docs-sphinx buildbot after 7225c0bd0115c947f3c081599e6268cfa027722f

HowToReleaseLLVM: Add annual release schedule template

Reviewed By: ldionne, thieta

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

HowToReleaseLLVM: Add some more details about website updates

Reviewed By: thieta

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

workflows/llvm-project-tests: Workaround an issue with lldb builds on Windows

For some reason cmake started selecting a 32-bit version of python on
Windows instead of the 64-bit version when building windows.  Explicitly
setting the default python to 3.10 fixes this problem.

Reviewed By: thieta

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

Fix unused variable warnings

These warnings came up with gcc-11.3.0.

Reland "[lldb] [test] Disable new CommunicationTests on Windows"

This change was wrongly reverted and re-broke the Windows buildbot.

Sponsored by: The FreeBSD Foundation

[NFC][AMDGPU] Fix typo.

[mlir][docs] Migrate away from deprecated llvm::Optional methods

[lldb] [gdb-remote] Include PID in vCont packets if multiprocess

Try to always send vCont packets and include the PID in them if running
multiprocess.  This is necessary to ensure that with the upcoming full
multiprocess support always resumes the correct process without having
to resort to the legacy Hc packets.

Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D131758

(Reland) [fastalloc] Support allocating specific register class in fastalloc

This reverts commit 853bb192c407f5d9e75a5fd55cc089151530cbd3.

workflows/version-check: Fix check for release candidates

Reviewed By: thieta

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

[lldb] Use Optional::value instead of Optional::getValue (NFC)

[lldb] Use Optional::transform instead of Optional::map (NFC)

[msan] Bump max allocation on aarch64

[MC][LoongArch] Make .reloc support arbitrary relocation types

Similar to D76746 (ARM), D76754 (AArch64), D77018 (RISCV)  and
llvmorg-11-init-6967-g152d14da64c (x86)

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

[LoongArch] Add some fixups and relocations

This patch only add %pc_hi20/%pc_lo12/%plt relocations in order
to be able to generate gnu ld linkable relocation file for the
`hello world` IR :
```
@.str = private unnamed_addr constant [14 x i8] c"Hello world!\0A\00", align 1

define dso_local signext i32 @main() nounwind {
entry:
  %call = call signext i32 (ptr, ...) @printf(ptr noundef @.str)
  ret i32 0
}

declare dso_local signext i32 @printf(ptr noundef, ...)
```

This patch also updates some test cases due to new modifiers introduced.
New test: test/MC/LoongArch/Relocations/relocations.s

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