This patch lowers the `REDUCE` intrinsic call to the runtime equivalent
for scalar results. Call with array result will follow.

Doxygen allows for the `@throw`, `@throws`, and `@exception` commands to
have an attached argument indicating the type being thrown. Currently,
Clang's AST parsing doesn't support parsing out this argument from doc
comments. The result is missing compatibility with Doxygen.

This PR implements parsing of arguments for the `@throw`, `@throws`, and
`@exception` commands. Each command can only have one argument, matching
the semantics of Doxygen.

Generalize logic to set the result type for ops where the result type
and the types of all operands match. Use it to support any unary and
binops.

Fix https://github.com/llvm/llvm-project/pull/88955

A block represents a chunk of memory used by the freelist allocator. It
contains header information denoting the usable space and pointers as
offsets to the next and previous block.

On it's own, this doesn't do much. This is a part of
https://github.com/llvm/llvm-project/pull/94270 to land in smaller
patches.

This is a subset of pigweed's freelist allocator implementation.

It does not look like 2000 is needed here in particular.

Follow up to #89464

`blendv` instructions are very similar to `select`.
We will add support for them in followup patches.

This fixes two problems with the 2-stage PGO builds. The first problem
was that the stage2-instrumented and stage2 targets would not be built
on the second ninja invocation. For example:

This would work as expected.
$ ninja -v -C build stage2-instrumented-generate-profdata

Edit a file.
$ touch llvm/lib/Support/StringExtras.cpp

This would rebuild stage1 only and not build stage2-instrumented or
regenerate the profile data.
$ ninja -v -C build stage2-instrumented-generate-profdata

The second problem was that in some cases, the profile data would be
regenerated, but not all of the stage2 targets would be rebuilt. One
common scenario where this would happen is:

This would work as expected.
$ ninja -C build stage2-check-all

This would regenerate the profile data, but then only build the
targets that were needed for install, but weren't needed for
check-all.  This would cause errors like:
ld.lld: error: Function Import: link error: linking module flags
'ProfileSummary': IDs have conflicting values in ...
 This is because the executibles being built for the install target
used the new profile data, but they were linking with libraries that
used the old profile data.
$ ninja -C build stage2-install

With this change we can re-enable PGO for the release builds.

This commit simplifies and improves documentation for the part of the
`ConversionPatternRewriter` API that deals with signature conversions.

There are now two public functions for signature conversion:
* `applySignatureConversion` converts a single block signature. This
function used to take a `Region *` (but converted only the entry block).
It now takes a `Block *`.
* `convertRegionTypes` converts all block signatures of a region.

`convertNonEntryRegionTypes` is removed because it is not widely used
and can easily be expressed with a call to `applySignatureConversion`
inside a loop. (See `Detensorize.cpp` for an example.)

Note: For consistency, `convertRegionTypes` could be renamed to
`applySignatureConversion` (overload) in the future. (Or
`applySignatureConversion` renamed to `convertBlockTypes`.)

Also clarify when a type converter and/or signature conversion object is
needed and for what purpose.

Internal code refactoring (NFC) of `ConversionPatternRewriterImpl` (the
part that deals with signature conversions). This part of the codebase
was quite convoluted and unintuitive.

From a functional perspective, this change is NFC. However, the public
API changes, thus not marking as NFC.

Note for LLVM integration: When you see
`applySignatureConversion(region, ...)`, replace with
`applySignatureConversion(region->front(), ...)`. In the unlikely case
that you see `convertNonEntryRegionTypes`, apply the same changes as
this commit did to `Detensorize.cpp`.

---------

Co-authored-by: Markus Böck <markus.boeck02@gmail.com>

Reapply "[libc][math][c23] Add MPFR unit tests for {ceil,floor,round,roundeven,trunc}f16 (#94383)" (#94807)

This reverts commit cbe97e95.

LSR will generate chains of related instructions with a known increment
between them. With SVE, in the case of the test case, this can include
increments like 'vscale * 16 + 8'. The idea of this patch is if we have
a '+8' increment already calculated in the chain, we can generate a
(legal) '+ vscale*16' addressing mode from it, allowing us to use the
'[x16, #1, mul vl]' addressing mode instructions.

In order to do this we keep track of the known 'bases' when generating
chains in GenerateIVChain, checking for each if the accumulated
increment expression from the base neatly folds into a legal addressing
mode. If they do not we fall back to the existing LeftOverExpr, whether
it is legal or not.

This is mostly orthogonal to #88124, dealing with the generation of
chains as opposed to rest of LSR. The existing vscale addressing mode
work has greatly helped compared to the last time I looked at this,
allowing us to check that the addressing modes are indeed legal.

See Buildbot failure:
https://lab.llvm.org/buildbot/#/builders/229/builds/27009.

There's only one way to create unnamed symbols (createTempSymbol).
Previously, the name was evaluated unconditionally, but often
unnecessarily. Avoid this.

Also the parameter names in the header were wrong, fix these.

This patch fixes:

  bolt/lib/Rewrite/DWARFRewriter.cpp:187:18: error: private field
  'Rewriter' is not used [-Werror,-Wunused-private-field]

Note that:

  commit 61df854d
  Author: Sayhaan Siddiqui <49014204+sayhaan@users.noreply.github.com>
  Date:   Mon Jun 10 10:46:20 2024 -0700

removed the last use of Rewriter.

Fix gen-static-analyzer-docs.py script.
Commit doc for:
 - clang-analyzer-cplusplus.ArrayDelete
 - clang-analyzer-security.SetgidSetuidOrder
 - clang-analyzer-unix.Stream

Reverts llvm/llvm-project#95006

Seems like there's some bug where the section name is empty in the `if
(!Section.isSingleStringRef())`. Revert for now to get builds back to
green.

Low 4 and high 4 bits of mask have a different purpose.

Irrelevant for the current implementation, but
will be used in the followup patches.

This avoid std::map, which is slow, and uses a StringMap. Section name,
group name, linked-to name and unique id are encoded into the key for
fast lookup.

This gives a measurable performance boost (>3%) for applications that
compile many small object files (e.g., functions in JIT compilers).

RelaxAll was set in the constructor, but cleared after reset().

When dropping DLL attributes, ensure that the most recent declaration is
being checked.

Attributes are mostly irrelevant to these tests, but very unstable,
and change from patch to patch.

This line was tripping the -Wglobal-constructor warning which was
causing a build failure when -Werror was turned on.

This patch implements the changes to LLVM IR discussed in

https://discourse.llvm.org/t/rfc-update-branch-weights-metadata-to-allow-tracking-branch-weight-origins/75032

In this patch, we add an optional field to MD_prof metadata nodes for
branch weights, which can be used to distinguish weights added from
`llvm.expect*` intrinsics from those added via other methods, e.g.
from profiles or inserted by the compiler.

One of the major motivations, is for use with MisExpect diagnostics,
which need to know if branch_weight metadata originates from an
llvm.expect intrinsic. Without that information, we end up checking
branch weights multiple times in the case if ThinLTO + SampleProfiling,
leading to some inaccuracy in how we report MisExpect related
diagnostics to users.

Since we change the format of MD_prof metadata in a fundamental way, we
need to update code handling branch weights in a number of places.

We also update the lang ref for branch weights to reflect the change.

from PEP8
(https://peps.python.org/pep-0008/#programming-recommendations):

> Comparisons to singletons like None should always be done with is or
is not, never the equality operators.

Two ways to relaxed:
    1) Only require one of the `and` ops to be single-use if both `X`
       and `Y` are constant.
    2) Special case, if `X ^ Y` is a negative power of 2, then
       `Z ^ NegP2 ==/!= 0` will fold to `Z u</u>= -NegP2` which
       creates no additional instructions so fold irrelivant of
       use counts.

Closes #94867

This patch tightens the assert check for the ABISP object in
`StopInfoMachException::DeterminePtrauthFailure`.

This causes some failure when debugging on a system that doesn't have
pointer authentification support, like on Intel for instance.

rdar://129401926



Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>

Replace old usages of GDB Index functions to use the new class.

A `sparse_tensor.iterate` iterates over a sparse iteration space
extracted from `sparse_tensor.extract_iteration_space` operation
introduced in https://github.com/llvm/llvm-project/pull/88554.

The current default, build-id=fast, is only 8 bytes due to the usage of
64-bit XXH3. This is incompatible with RPM packaging tools which
requires >=16 bytes [1].

In Clang the ENABLE_LINKER_BUILD_ID define makes it pass --build-id
without a specific hash type. When also defaulting to LLD, this provides
a pretty broken default out-of-box.

Using XXH3 was a considerable performance advantage when build-id was
first implemented, because sha1 was really sha1 and rather slow.
Nowadays sha1 is just 160-bit BLAKE3 which is decently fast and not
cryptographically broken, so it should be a good default.

Note that the default remains "fast" for wasm because sha1 for wasm is
still real sha1.

Close https://github.com/llvm/llvm-project/issues/43483.

[1]:
https://github.com/rpm-software-management/rpm/blob/b7d427728b8ba8734ba47d51849a5736bdd727cd/build/files.c#L1883

In a similar way to how we push vector adds into extends, this pushed
'mul(zext,zext)' into 'zext(mul(zext,zext))' if the extend can be done
in two or more steps.

https://alive2.llvm.org/ce/z/WjU7Kr

Don't use %a and %A in the same test as FileCheck doesn't like it.

Additional multi-use tests for #94948

Fixes type check failure in
https://github.com/llvm/llvm-project/pull/94110#issuecomment-2158417937

It's needed to make clang-repl work in -DCLANG_PLUGIN_SUPPORT=OFF
configured builds (at least on mac). See discussion on
https://github.com/llvm/llvm-project/pull/89811