Currently there're two pages that both talk about "Modules" in clang, but
they're different. The one that describes C++ standard modules explicitly
spells out the difference but the other one which targeting Clang modules
doesn't.

This patch adds a link that refers to the C++ standard modules
one in Clang modules doc, as you usually got the later page when
googling. I believe this will make newcomers less confused.

Signed-off-by: Jun Zhang <jun@junz.org>

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

compressed_pair is widely used in the library, but most of the uses don't use the tuple parts. To avoid including <tuple> everywhere, use the forward declaration instead in compressed_pair.h

Reviewed By: ldionne, #libc

Spies: libcxx-commits

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

Closing https://github.com/llvm/llvm-project/issues/57778.

Previously it judge if we're compiling a module unit by
LangOpts::CurrentModule.empty(). But it is not true since we can specify
the module name by `-fmodule-name` option for arbitrary module unit.
Then this patch adjuest the judgement properly.

In the past, we've had a bug resulting in a compiler crash after
forgetting to merge function attributes (D105729).

This patch teaches InlineFunction to merge function attributes.  This
way, we minimize the "time" when the IR is valid, but the function
attributes are not.

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

We check to see if a given CallBase is a sole call to a local function
at multiple places in InlineCost.cpp.  This patch factors out the
common code.

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

Reviewed by: Florian Hahn

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

The following changes are necessasy to get the generated tree
matcher to compile:

- In CodeExpansions::declare(), the assert() prevents connecting
  two instructions. E.g. the match code
    (match (MUL $t, $s1, $s2),
           (SUB $d, $t, $s3)),
  results in two declarations of $t, one for the def and one for
  the use. Removing the assertion allows this construct.
  If $t is later used, it is one of the operands, which should be
  perfectly fine.
- The code emitted in GIMatchTreeVRegDefPartitioner::generatePartitionSelectorCode()
  is not compilable:
  - The value of NewInstrID should be emitted, not the name
  - Both calls involving getOperand() end with one parenthesis too many
- Swaps generated condition for the partition code in the latter function

It also changes the rules i2p_to_p2i, fabs_fabs_fold, and fneg_fneg_fold
to use the tree matcher for a linear match. These rules are tested by:

CodeGen/AArch64/GlobalISel/combine-fabs.mir
CodeGen/AArch64/GlobalISel/combine-fneg.mir
CodeGen/AArch64/GlobalISel/combine-ptrtoint.mir
CodeGen/AMDGPU/GlobalISel/combine-add-nullptr.mir

Reviewed By: arsenm

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

It makes more sense to set Changed to true immediately after a
successful inlining.

Most of the state traits used for non-POD array evaluation were
only cleaned up if the ctors/dtors were inlined, since the cleanup
happened in ExprEngine::processCallExit(). This patch makes sure
they are removed even if said functions are not inlined.

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

This patch adds in instruction based features to the regalloc advisor
gated behind a flag so a user can decide at runtime whether or not they
want to enable the feature. The features are only enabled when LLVM is
compiled in MLGO develpment mode (LLVM_HAVE_TF_API) is set to true.

To extract the instruction features, I'm taking a list of segments from
each LiveInterval and noting the start and end SlotIndices. This list is then
sorted based on the start SlotIndex and I iterate through each SlotIndex
to grab instructions, making sure to check for overlaps. This results in
a vector of opcodes and binary mapping matrix that maps live ranges to the
opcodes of the instructions within that LR.

Reviewed By: mtrofin

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

llvm/lib/ProfileData/RawMemProfReader.cpp uses SetVector without
including SetVector.h, so this patch adds an appropriate #include
there.

This improves consistency with other places (e.g. llvm::compression::decompress,
llvm::object::Decompressor::decompress, llvm-objcopy).
Note: when zstd::uncompress was added, we noticed that the API `ZSTD_decompress`
is fine while the zlib API `uncompress` is a misnomer.

We don't use SetVector in the module inliner.

While I am at it, this patch removes an unnecessary forward
declaration.

UseInlinePriority specifies the priority function.  This patch
simplifies the code by moving UseInlinePriority closer to the actual
consumer -- the switch statement inside getInlineOrder.

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

This adds the intrinsics:
* void @llvm.aarch64.sme.za.enable() -> smstart za
* void @llvm.aarch64.sme.za.disable()  -> smstop za

Reviewed By: aemerson

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

[AArch64][SME] Disable tail-call optimization when streaming mode change or lazy-save may be required.

When a streaming mode change is (or may be) required for a call, it will
need to restore the original mode after the call, which prevents the use of
tail-call optimization. The same holds true for a call that requires the lazy-save
mechanism to be set up before the call, and possibly restored after.

More details about the SME attributes and design can be found
in D131562.

Reviewed By: aemerson

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

This removes a lot of boilerplate code.

Reviewed By: ldionne, #libc

Spies: EricWF, libcxx-commits

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

Implements paper P2324R2
https://wg21.link/p2324r2
https://github.com/cplusplus/papers/issues/1006

Reviewed By: cor3ntin

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

After compilation errors, expression a transformation result may not be usable.
It triggers an assert in RemoveNestedImmediateInvocation and SIGSEGV in case of
builds without asserts. This issue significantly affects clangd because source
may not be valid during typing. Tests cases that I attached was reduce from huge
C++ translation unit.

Test Plan: check-clang

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

f213128b didn't account for the possibility that the result of
decompose may be empty. Fix that by explicitly checking. Use a newly
introduced helper to also reduce some duplication.

Thanks @bjope for finding the issue!

It may help users to better understand the change by showing them a
contrived code example which demonstrates the difference in behavior.

Reviewed By: ldionne, #libc

Spies: libcxx-commits, jeroen.dobbelaere

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

Uses double backticks where appropriate, changes some instances of
GH12345 to be Issue 12345, etc.

The test is failing because it lacks a target triple, so the number of
diagnostics differs between Windows and Linux targets.

This should correct the issue found by:
https://lab.llvm.org/buildbot/#/builders/109/builds/46804

We would diagnose use of `long long` as an extension in C89 and C++98
modes when the user spelled the type `long long` or used the `LL`
literal suffix, but failed to diagnose when the literal had no suffix
but required a `long long` to represent the value.

Wrap implicit dependencies in Label() so that they refer to @llvm-project, see https://bazel.build/rules/lib/Label#Label.

This change allows lit_test() to be used from other bazel repositories.

Baseline tests for D131786

One of the vector transformation patterns has been indiscriminately
converting layouts to affine maps. Leverage the strided form when
possible.

Reviewed By: nicolasvasilache, dcaballe

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

All relevant operations have been switched to primarily use the strided
layout, but still support the affine map layout. Update the relevant
tests to use the strided format instead for compatibility with how ops
now print by default.

Reviewed By: nicolasvasilache

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