Having the header granularized makes it possible to remove the
dependency on this header in <format>. This <format> header gets
included in more headers due to more usage of std::formatter in the
library. This should reduce the number of transitive includes.

Note formatting the new headers will be done in a followup patch.

Reviewed By: #libc, ldionne

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

I noticed this wile investigating https://llvm.org/PR61314

Reviewed By: #libc, ldionne

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

Catch invalid element type in fir.box in the verifier so
it does not propagate later in lowering.

Reviewed By: PeteSteinfeld

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

Adapat the fix made in D146079 to just avoid the type
to be wrapped with an extra fir.box or fir.class. The potential
load is delegated to the code that is after.

Reviewed By: PeteSteinfeld

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

Since debugify inserts instructions.

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

This makes it so that calling `llvm::is_contained` no longer degrades
performance over member contains, even though both have almost identical
names. This would be the case in most set/map classes that can check for
an element being present in O(1) or O(log n) time vs. linear scan with
`std::find`. For C++17 maps/sets without `.contains`, use `.find` when available,
falling back to a linear scan with `std::find`.

I also considered detecting member contains and triggering a
`static_assert` instead, but decided against it because it's just as easy
to do the right thing and call `.contains`. This would also make some code fail
only when compiled in the C++20 mode when more container types come with
`.contains` member functions.

This was actually already the case with `CommandLine.h` calling `is_contained`
on `SmallPtrSet` and in a recent BOLT patch.

Reviewed By: kazu, dblaikie, MaskRay

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

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

[clang][RISCV][NFC][test] Move riscv-abi.cpp and riscv{32,64}-*abi.c tests to use update_cc_test_checks.py

This patch implements an initial step towards refactoring our ABI tests
(moving them to update_cc_test_checks.py). Future patches combine them.

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

https://llvm-compile-time-tracker.com/compare.php?from=3fd42f50d8aadb4d0c348ac17cd2115c1b0564a4&to=50c37f6fc62a1e7bb4f0e307c89f760d42dbe4e9&stat=instructions:u
shows that this is fairly expensive, 5-10% increase in compile time, and I'd like to add more similar checks under the same flag.

This matches the legacy pass manager.

Reviewed By: nikic

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

This allows instrumentation to inspect cached analyses to verify them.

The CGSCC PassInstrumentation previously ran `runAfterPass()` on the original SCC, but really it should be running on UpdatedC when relevant since that's the relevant SCC after the pass.

Reviewed By: nikic

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

When fsource or tsource is not polymorphic, the result is not
polymorphic. Rebox the polymoprhic arguement so the dynamic
type of the result is correct.

Reviewed By: PeteSteinfeld

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

This patch adds handling of DW_FORM_implicit_const form.

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

Reviewed By: foad

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

This patch adjusts the memory instrumentation to account for scalable vector types in allocas. Note that we don't allow scalable vector globals, so we don't need to update that codepath.

A couple points.

First, this simply disables the optimization for scalable allocas. We can revisit this in the future, but it requires a bit of plumbing to get scalable object sizes through the visitor to be useful.

Second, I am simply disabling stack poisoning for scalable vector allocas. This is mostly for staging the change as I can't write a working test for memory instrumentation without doing so. I don't think it's unreasonable to do on it's own basis as without the bailout, we crash the compiler.

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

Replace references to enumerate results with either result_pairs
(reference wrapper type) or structured bindings. I did not use
structured bindings everywhere as it wasn't clear to me it would
improve readability.

This is in preparation to the switch to zip semantics which won't
support non-const lvalue reference to elements:
https://reviews.llvm.org/D144503.

I chose to use values instead of const lvalue-refs because MLIR is
biased towards avoiding `const` local variables. This won't degrade
performance because currently `result_pair` is cheap to copy (size_t
+ iterator), and in the future, the enumerator iterator dereference
will return temporaries anyway.

Reviewed By: dblaikie

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

Implements parts of P1614R2: `operator<=>` for `map` and `multimap`

Reviewed By: #libc, philnik

Spies: philnik, libcxx-commits, yaxunl

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

For D141247 - if that pattern was used by GISel it could cause constant bus limitation failures.
Just use inline immediates instead of S_MOV to avoid the issue.

Reviewed By: arsenm

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

This is an alternative fix to D145497, which also addresses
  https://github.com/llvm/llvm-project/issues/60918

In D124457 which added the original code for this, @efriedma pointed
out that it wasn't safe to assume that FI #0 would be allocated at offset
0, but that part of the patch went in without any changes.

The downside of this solution is that any access to an object on the
stack that has been allocated at SP + 0, still gets moved to a separate
register first, which degrades performance.

Reviewed By: paulwalker-arm

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

llvm-debuginfo-analyzer is a command line tool that processes debug
info contained in a binary file and produces a debug information
format agnostic “Logical View”, which is a high-level semantic
representation of the debug info, independent of the low-level
format.

https://discourse.llvm.org/t/llvm-dev-rfc-llvm-dva-debug-information-visual-analyzer/62570

This patch:

Contains notes collected during the development, review and test.
It describes limitations, know issues and future work.

Reviewed By: Orlando

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

Make it clear this is referring to DemandedBits not DemandedElts.

This commit allows libclang API users to opt into storing PCH in memory
instead of temporary files. The option can be set only during CXIndex
construction to avoid multithreading issues and confusion or bugs if
some preambles are stored in temporary files and others - in memory.

The added API works as expected in KDevelop:
https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/283

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

These functions are available on the `OpBuilder` API.

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

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

Extend the existing store(load()) removal code to account for intermediate truncates that some targets won't remove with canCombineTruncStore - we only care about the load/store MemoryVT.

Fixes regression from D146121

On SystemZ, int128 values are generally aligned to only 8 bytes per the ABI
while 128 bit atomic ISA instructions exist with a full 16 byte alignment
requirement.

__sync builtins are emitted as atomicrmw instructions which always require
the natural alignment (16 bytes in this case), and they always get it
regardless of the alignment of the value being addressed.

This patch improves this situation by giving a warning if the alignment is
not known to be sufficient. This check is done in CodeGen instead of in Sema
as this is currently the only place where the alignment can be computed. This
could/should be moved into Sema in case the alignment computation could be
made there eventually.

Reviewed By: efriedma, jyknight, uweigand

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

Fix the issue of .o file generated by `Flang`
with `Flags` info is 0x0 under RISC-V.

Reviewed By: awarzynski, kiranchandramohan

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

This was preventing lit from being uploaded to pypi.

Reviewed By: mgorny

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

This needs to consider the denormal mode.

This reverts commit 458ad690.

This implements support for two new 2022 A-profile extensions:
- FEAT_CHK - Check Feature Status Extension
- FEAT_GCS - Guarded Control Stacks

FEAT_CHK is mandatory from armv8.0-a, but is in the hint space so
there's no clang command-line flag for it, and we only print the hint as
`chkfeat x16` at v8.9a and above, to be compatible when using a
non-integrated assembler that might not yet know about the extension.

FEAT_GCS is optional from armv9.4-a onwards. It is enabled using `+gcs`
in a clang `-march=` or `-mcpu=` option string, or using a
`.arch_extension gcs` assembly directive.

This patch includes changes by Ties Stuij, Tomas Matheson, and Keith
Walker.

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

This patch adds support of DWARFv5 .debug_loclists table.
As DWARFLinker resolves relocations, it is able to always
use DW_FORM_addr instead of DW_FORM_addrx. DW_FORM_addrx
helps to minimize number of relocations, it is also used for
split DWARF. Both of these cases are not relevant for the
DWARFLinker. Thus, this patch converts all DW_FORM_addrx
forms into the DW_FORM_addr. And, as the result, it converts
location lists of DW_FORM_loclistx form into the DW_FORM_sec_offset.
For the --update case all DW_FORM_addrx, DW_FORM_loclistx
are preserved as is.

Depends On D145499

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

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