The current command will raise an error:

> The `opt -passname` syntax for the new pass manager is not supported,
please use `opt -passes=<pipeline>` (or the `-p` alias for a more
concise version).

Update the usage now.

This patch is to extract the NFC in #76319 into a separate commit.

This is needed because Windows doesn't have anything equivalent to the
POSIX fnmatch() function.

This patch adds support for `__riscv_clmulr_32/64` in `riscv_bitmanip.h`.
It also fixes the extension requirements of `clmul/clmulh`.

This patch replaces `__builtin_riscv_cpop_32/64` with `__builtin_popcount(ll)` because `__builtin_riscv_cpop_32/64` is not implemented in clang.

This avoids the UB and makes things a bit cheaper in terms of
compile-times.

For legacy (arithmetic) instructions, the operand size override prefix (0x66)
is used to switch the operand data size from 32b to 16b (in 32/64-bit mode),
16b to 32b (in 16-bit mode). That's why we set OpSize16 for 16-bit instructions
and set OpSize32 for 32-bit instructions.

But it's not a generic rule any more after APX. APX adds 4 variants for
arithmetic instructions: promoted EVEX, NDD (new data destination), NF (no flag),
NF_NDD. All the 4 variants are in EVEX space and only legal in 64-bit
mode. EVEX.pp is set to 01 for the 16-bit instructions to encode 0x66.
For APX, we should set OpSizeFixed for 8/16/32/64-bit variants and set PD for
the 16-bit variants.

Hence, to reuse the classes ITy and its subclasses BinOp* for APX instructions,
we extract the OpSize setting from the class ITy.

It helps simplify the class definitions. Now, the only explicit usage of PS is
to check prefix 0x66/0xf2/0xf3 can not be used a prefix, e.g. wbinvd.

See 82974e01 for more details.

Followup to #76279

Fixes https://github.com/llvm/llvm-project/issues/76270

.

Thanks to @scottamain for the clear description.


Co-authored-by: Scott Main <scott@modular.com>

Commit 1b531d54 (#74203) removed the usage of unique_ptrs of arrays
in favour of using vectors, but inadvertently increased peak memory
usage by removing the ability to deallocate vector memory that was no
longer needed mid-LDV.

In that same review, it was pointed out that `FuncValueTable` typedef
could be removed, since it was "just a vector".

This commit addresses both issues by making `FuncValueTable` a real data
structure, capable of mapping BBs to ValueTables and able to free
ValueTables as needed.

This reduces peak memory usage in the compiler by 10% in the benchmarks
flagged by the original review.

As a consequence, we had to remove a handful of instances of the
"declare-then-initialize" antipattern in unittests, as the
FuncValueTable class is no longer default-constructible.

The constraint system used for ConstraintElimination assumes all
varibles to be signed. This can cause missed optimization in the
unsigned system, due to missing the information that all variables are
unsigned (non-negative).

Variables can be marked as non-negative by adding Var >= 0 for all
variables. This is done for arguments on ConstraintInfo construction and
after adding new variables. This handles cases like the ones outlined in
https://discourse.llvm.org/t/why-does-llvm-not-perform-range-analysis-on-integer-values/74341

The original example shared above is now handled without this change,
but adding another variable means that instcombine won't be able to
simplify examples like https://godbolt.org/z/hTnra7zdY

Adding the extra variables comes with a slight compile-time increase
https://llvm-compile-time-tracker.com/compare.php?from=7568b36a2bc1a1e496ec29246966ffdfc3a8b87f&to=641a47f0acce7755e340447386013a2e086f03d9&stat=instructions:u

stage1-O3    stage1-ReleaseThinLTO    stage1-ReleaseLTO-g  stage1-O0-g
 +0.04%           +0.07%                   +0.05%           +0.02%
stage2-O3    stage2-O0-g    stage2-clang
  +0.05%         +0.05%        +0.05%

https://github.com/llvm/llvm-project/pull/76262

Recent CI changes have disabled testing modules in different
configurations. This broke building the std and std.compat module in
C++20. This was found by the CI in #76246.

Fixes #70238

This is preparation for performance optimization.

We need to highlight that this is very specific lock, and should not be
used for other purposes.
Add `fork_child` parameter to distinguish processes after fork.

Fixes llvm/llvm-project#74901

Annotates function declaration names having unnamed parameters.

I missed this when converting other scalar bitmanip/crypto tests
to use intrinsics intead of builtins.

Reported by Static Analyzer Tool:

In ​EmitAssemblyHelper::​RunOptimizationPipeline(): Using the auto
keyword without an & causes the copy of an object of type function.

 /// List of pass builder callbacks ("CodeGenOptions.h").
std::vector<std::function<void(llvm::PassBuilder &)>>
PassBuilderCallbacks;

9eb80ab3 changed the method for stack
pointer restoration to fix segmentation faults. However, I made a
mistake in the patch and swapped a != for a ==, which caused an
arbitrary register (the first one specified) to get restored rather than
the stack pointer specifically. This patch fixes that issue and adds
test coverage to prevent regression.

Reverts llvm/llvm-project#76232 and
7ab16fb5 to recover build bots.

Breaks libc++ tests, details in #76232

#76228

This will help distinguish release branch builds from development branch
builds, and is similar to GCC's version numbering policy.

Thus, the branch `releases/18.x` will start out numbered 18.1.0, instead
of 18.0.0.

Unchanged are other versioning policies:
- mainline will be numbered 18.0.0, 19.0.0, ...
- typical release branch releases will increment micro version, e.g.
18.1.1, 18.1.2, ....
- If an ABI break is required on the release branch, the minor version
will be incremented, e.g. to 18.2.0.

See the Discourse RFC:

https://discourse.llvm.org/t/rfc-name-the-first-release-from-a-branch-n-1-0-instead-of-n-0-0/75384

This was an oversight that seems to be causing problems on certain
builds. This patch should fix #76225.

This patch tries to fold minmax intrinsic by using
`computeConstantRangeIncludingKnownBits`.
Fixes regression in
[_karatsuba_rec:cpython/Modules/_decimal/libmpdec/mpdecimal.c](https://github.com/python/cpython/blob/c31943af16f885c8cf5d5a690c25c366afdb2862/Modules/_decimal/libmpdec/mpdecimal.c#L5460-L5462),
which was introduced by #71396.
See also
https://github.com/dtcxzyw/llvm-opt-benchmark/issues/16#issuecomment-1865875756.

Alive2 for splat vectors with undef: https://alive2.llvm.org/ce/z/J8hKWd

Summary:
Adding information to the LIBOMPTARGET profiler runtime kernel and API
calls.

Key changes:
* Adding information to runtime calls for better understanding of how
the application
is executing. For example teams requested by the user, size of memory
transfers.
* Profile timer was changed from 'us' to 'ns', since 'us' was too
coarse-grain
  to register some important details like key kernel duration
* Removed non API or Runtime calls, to reduce complexity of profile for
application
  developers.

---------

Co-authored-by: Felipe Cabarcas <cabarcas@leia.crpl.cis.udel.edu>
Co-authored-by: fel-cab <fel-cab@github.com>

Based on https://godbolt.org/z/hTnra7zdY, which is a slightly more
complicated version of the example from
https://discourse.llvm.org/t/why-does-llvm-not-perform-range-analysis-on-integer-values/74341

Emits MLIR op corresponding to `!$omp target update` directive. So far,
only motion types: `to` and `from` are supported. Motion modifiers:
`present`, `mapper`, and `iterator` are not supported yet.

This is a follow up to #75047 & #75159, only the last commit is relevant
to this PR.

No behavior change.