Some platforms don't provide all C library headers. In practice, libc++
only requires a few C library headers to exist, and only a few functions
on those headers. Missing functions that libc++ doesn't need for its own
implementation are handled properly by the using_if_exists attribute,
however a missing header is currently a hard error when we try to
do #include_next.

This patch should make libc++ more flexible on platforms that do not
provide C headers that libc++ doesn't actually require for its own
implementation. The only downside is that it may move some errors from
the #include_next point to later in the compilation if we actually try
to use something that isn't provided, which could be somewhat confusing.
However, these errors should be caught by folks trying to port libc++
over to a new platform (when running the libc++ test suite), not by end
users.

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

Ports:
* https://reviews.llvm.org/D84023
* https://reviews.llvm.org/rG4f5ccc72f6a6e
  (but see https://reviews.llvm.org/rG4901199f5b84b223)

No intended behavior change.

On x86 and AArch, SIMD instructions encode all of the scheduling information in the instruction
itself. For example, VADD.I16 q0, q1, q2 is a neon instruction that operates on 16-bit integer
elements stored in 128-bit Q registers, which leads to eight 16-bit lanes in parallel. This kind
of information impacts how the instruction takes to execute and what dependencies this may cause.

On RISCV however, the data that impacts scheduling is encoded in CSR registers such as vtype or
vl, in addition with the instruction itself. But MCA does not track or use the data in these
registers. This patch fixes this problem by introducing Instruments into MCA.

* Replace `CodeRegions` with `AnalysisRegions`
* Add `Instrument` and `InstrumentManager`
* Add `InstrumentRegions`
* Add RISCV Instrument and `InstrumentManager`
* Parse `Instruments` in driver
* Use instruments to override schedule class
* RISCV use lmul instrument to override schedule class
* Fix unit tests to pass empty instruments
* Add -ignore-im clopt to disable this change

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

This allow recognition of when a ptest was emitted as an any condition
and allows for extra optimization to be done later.

This addresses missing optimizations from D137716 and D137718, and
partially D137717.

Depends on D137716, D137717, D137718

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

After D138014 we do not support using AST with IR that is being
mutated. As such, we also no longer need to track unknown
instructions using WeakVH. Replace with AssertingVH to make sure
that they are not invalidated.

Refer to _LIBCPP_ENABLE_DEBUG_MODE instead of the old _LIBCPP_DEBUG
in a comment, and write that to __config_site correctly too.

See 13ea1343 and the comments in https://crbug.com/1358646.

Also change the default of libcxx_enable_debug_mode to false for now.
Since we used to not write _LIBCPP_ENABLE_DEBUG_MODE, the previous
default of true had no effect (except for compiling debug.cpp and
legacy_debug_handler.cpp, which we now no longer build by default).
So this (mostly) preserves previous behavior.

This reverts commit 47459455.

Revert while I try to fix a couple of non-Linux build failures.

This restricts usage of AliasSetTracker to IR that does not change.
We used to use it during LICM where the underlying IR could change,
but remaining uses all use AST as part of a separate analysis phase.

This is split out from D137955, which makes use of the new guarantee
to switch to BatchAA.

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

The Assignment Tracking debug-info feature is outlined in this RFC:

https://discourse.llvm.org/t/
rfc-assignment-tracking-a-better-way-of-specifying-variable-locations-in-ir

The SLP-Vectorizer can merge a set of scalar stores into a single vectorized
store. Merge DIAssignID intrinsics from the scalar stores onto the new
vectorized store.

Reviewed By: jmorse

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

The issue that caused the revert has been fixed in:
44bd8075

-----

This switches Hexagon intrinsics to use the default attributes
(nosync, nofree, nocallback and willreturn). Especially willreturn
is needed to prevent optimization regressions in the future.

The only intrinsics I've excluded here are the load/store locked
intrinsics, which presumably aren't nosync.

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

The Assignment Tracking debug-info feature is outlined in this RFC:

https://discourse.llvm.org/t/
rfc-assignment-tracking-a-better-way-of-specifying-variable-locations-in-ir

This test covers the NFC-for-normal-debug-info change D133303.

Reviewed By: jmorse

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

document

Make the stack alignment register (AP) reserved in the given function. This
will make it available everywhere in the function, and allow aligned access
to vector register spill slots.

We have been transitioning off of that macro since LLVM 15.

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

Implements the ThinLTO summary support for memprof related metadata.

This includes support for the assembly format, and for building the
summary from IR during ModuleSummaryAnalysis.

To reduce space in both the bitcode format and the in memory index,
we do 2 things:
1. We keep a single vector of all uniq stack id hashes, and record the
   index into this vector in the callsite and allocation memprof
   summaries.
2. When building the combined index during the LTO link, the callsite
   and allocation memprof summaries are only kept on the FunctionSummary
   of the prevailing copy.

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

This feature was probably missed when adding FamilyAVR6, but should
definitely be there. I checked all four devices in the AVR6 family and
they all support eijmp/eicall.

Found while working on https://reviews.llvm.org/D137572.

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

This macro is defined in avr-gcc, and is very useful especially in
assembly code to check whether particular instructions are supported. It
is also the basis for other macros like __AVR_HAVE_ELPM__.

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

This simplifies the code by avoiding some special cases for family names
(as opposed to device names).

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

Adds support for options-controlled configuration of the check to ignore results in macros.

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

Overrides are constrained by the signature of the overridden method, so a
warning on an override is frequently unactionable.

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

The backward register scavenger has correct register
liveness information. PEI should leverage the backward register scavenger.

Reviewed By: arsenm

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

The Assignment Tracking debug-info feature is outlined in this RFC:

https://discourse.llvm.org/t/
rfc-assignment-tracking-a-better-way-of-specifying-variable-locations-in-ir

DeadStoreElimmination shortens stores that are shadowed by later stores such
that the overlapping part of the earlier store is omitted. Insert an unlinked
dbg.assign intrinsic with a variable fragment that describes the omitted part
to signal that that fragment of the variable has a stale value in memory.

Reviewed By: jmorse

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

This restores commit b756096b, which was
originally reverted in 00b09a7b.

AAPointerInfo now maintains a list of all Access objects that it owns, along
with the following maps:

- OffsetBins: OffsetAndSize -> { Access }
- InstTupleMap: RemoteI x LocalI -> Access

A RemoteI is any instruction that accesses memory. RemoteI is different from
LocalI if and only if LocalI is a call; then RemoteI is some instruction in the
callgraph starting from LocalI.

Motivation: When AAPointerInfo recomputes the offset for an instruction, it sets
the value to Unknown if the new offset is not the same as the old offset. The
instruction must now be moved from its current bin to the bin corresponding to
the new offset. This happens for example, when:

- A PHINode has operands that result in different offsets.
- The same remote inst is reachable from the same local inst via different paths
  in the callgraph:

```
               A (local inst)
               |
               B
              / \
             C1  C2
              \ /
               D (remote inst)

```
This fixes a bug where a store is incorrectly eliminated in a lit test.

Reviewed By: jdoerfert, ye-luo

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

The Assignment Tracking debug-info feature is outlined in this RFC:

https://discourse.llvm.org/t/
rfc-assignment-tracking-a-better-way-of-specifying-variable-locations-in-ir

In an attempt to preserve more info, don't delete dbg.assign intrinsics that
are considered "out of scope" if they're linked to instructions.

Reviewed By: jmorse

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

AArch64InstrInfo::optimizePTestInstr attempts to remove a PTEST of a
predicate generating operation that identically sets flags (implictly).

When the mask is an all active of matching element size the PTEST is
currently removed. For while instructions this is correct since they
perform an implicit PTEST with an all active mask. However, for other
instructions such as compares the mask could be different.

This patch fixes this bug by only removing the PTEST if the same all
active mask is used by the predicating-generating instruction.

Reviewed By: bsmith

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

I noticed that the values for __{CLANG,GCC}_ATOMIC_POINTER_LOCK_FREE were
incorrectly set to 1 instead of two in downstream CHERI targets because
pointers are handled specially there. While fixing this downstream, I
noticed that the existing code could be refactored to use
TargetInfo::hasBuiltinAtomic instead of repeating the almost identical
logic. In theory there could be a difference here since hasBuiltinAtomic() also
returns true for types less than 1 char in size, but since
InitializePredefinedMacros() never passes such a value this change should
not introduce any functional changes.

Reviewed By: rprichard, efriedma

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

The Assignment Tracking debug-info feature is outlined in this RFC:

https://discourse.llvm.org/t/
rfc-assignment-tracking-a-better-way-of-specifying-variable-locations-in-ir

Merge DIAssignID attachments on stores that are merged and sunk out of
loops. The store may be sunk into multiple exit blocks, and in this case all
the copies of the store get the same DIAssignID.

Reviewed By: jmorse

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

This patch adds the name convention for SME instructions.
This patch fixes the number of registers for LookUpTable in the AsmParser.
The number of registers is not used atm, but it is needed.
The switch case in getNumRegsForRegKind needs to have all the
RegKind enum.

Now the names for all ADD, SUB, FADD and FSUB array accumulators instructions
are consistent with the developer's page and their operands.

AArch64InstrInfo::optimizePTestInstr attempts to remove a PTEST of a
predicate generating operation that identically sets flags (implictly).

When the mask is the same as the input predicate the PTEST is currently
removed. This is incorrect since the mask for the implicit PTEST
performed by the flag-setting instruction differs from the mask
specified to the explicit PTEST and could set different flags.

For example, consider

  PG=<1, 1, x, x>
  Z0=<1, 2, x, x>
  Z1=<2, 1, x, x>

  X=CMPLE(PG, Z0, Z1)
   =<0, 1, x, x>       NZCV=0xxx
  PTEST(X, X),         NZCV=1xxx

where the first active flag (bit 'N' in NZCV) is set by the explicit
PTEST, but not by the implicit PTEST as part of the compare. Given the
PTEST mask and source are the same however, first is equivalent to any,
so the PTEST could be removed if the condition is changed. The same
applies to last active. It is safe to remove the PTEST for any active,
but this information isn't available in the current optimization.

This patch fixes the bad optimization, a later patch will implement the
optimization proposed above and fix the any active case.

Reviewed By: bsmith

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

The Assignment Tracking debug-info feature is outlined in this RFC:

https://discourse.llvm.org/t/
rfc-assignment-tracking-a-better-way-of-specifying-variable-locations-in-ir

Maintain and propagate DIAssignID attachments in memcpyopt.

Reviewed By: jmorse

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

The Assignment Tracking debug-info feature is outlined in this RFC:
https://discourse.llvm.org/t/
rfc-assignment-tracking-a-better-way-of-specifying-variable-locations-in-ir

mldst-motion will merge and sink the stores in if-diamond branches into the
common successor. Attach a merged DIAssignID to the merged store.

Reviewed By: jmorse

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

Follow up to 0946e463 (D133295).

The Assignment Tracking debug-info feature is outlined in this RFC:

https://discourse.llvm.org/t/
rfc-assignment-tracking-a-better-way-of-specifying-variable-locations-in-ir

The changes for assignment tracking in mem2reg don't require much of a
deviation from existing behaviour. dbg.assign intrinsics linked to an alloca
are treated much in the same way as dbg.declare users of an alloca, except that
we don't insert dbg.value intrinsics to describe assignments when there is
already a dbg.assign intrinsic present, e.g. one linked to a store that is
going to be removed.

Reviewed By: jmorse

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

Ensure we're testing the avx512vl gfni instructions and not the avx gfni instructions

Lower intrinsic assignment to hlfir.assign, except when the LHS
is a whole allocatable (this part will be done later to keep patch
simpler).

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

Add hlfir.assign that represent Fortran assignment.
See https://github.com/llvm/llvm-project/blob/main/flang/docs/HighLevelFIR.md.
Operation attributes will be added later when they can be used.

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