with --function-signature option (otherwise filecheck gets confused).

Plus fix a few wrong examples with undef

This reverts commit 8a3f9a58.

need to investigate build failures that do not show on CI or local
testing.

Rename %tmp => %temp IR values to avoid update warning.

In C++20 modules imports must be together and at the start of the module.
Rather than growing more ad-hoc flags to test state, this keeps track of the
phase of of a valid module TU (first decl, global module frag, module,
private module frag).  If the phasing is broken (with some diagnostic) the
pattern does not conform to a valid C++20 module, and we set the state
accordingly.

We can thus issue diagnostics when imports appear in the wrong places and
decouple the C++20 modules state from other module variants (modules-ts and
clang modules).  Additionally, we attempt to diagnose wrong imports before
trying to find the module where possible (the latter will generally emit an
unhelpful diagnostic about the module not being available).

Although this generally simplifies the handling of C++20 module import
diagnostics, the motivation was that, in particular, it allows detecting
invalid imports like:

import module A;

int some_decl();

import module B;

where being in a module purview is insufficient to identify them.

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

This is a partial port of the same optimization from AArch64ISelLowering,
although the original handles more cases when generating regular compares
instead of this one which just does it when selecting G_SELECTs.

For more detailed comments see the original comments for
emitConditionalComparison() in AArch64ISelLowering.

Gives minor code size improvements.

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

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

HIP programs compiled with -c -fgpu-rdc generate clang-offload-bundler
bundles which contain bitcode for different GPU's.

Such files can be archived to an archive file which can be linked with
HIP programs with -fgpu-rdc.

This patch adds suppor of linking archive of bundled bitcode.

When an archive of bundled bitcode is passed to clang by -l, for each
GPU specified through --offload-arch, clang extracts bitcode from
the archive and creates a new archive for that GPU and pass it
to lld.

Reviewed by: Artem Belevich

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

Fixes: SWDEV-321741, SWDEV-315773

This allows to differentiate between the cases where the optimum does not
exist due to being unbounded and due to the polytope being empty.

Reviewed By: Groverkss

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

The removed conditions are already checked by the if above.

Fixes #53761.

Add `BufferizableOpInterface::verifyAnalysis`. Ops can implement this method to check for expected invariants and limitations.

The purpose of this change is to introduce a modular way of checking assertions such as `assertScfForAliasingProperties`.

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

This code was detecting whether the value returned by getShiftAmountTy
can represent all shift amounts. If not, it would use MVT::i32 as a
placeholder. getShiftAmountTy was updated last year to return i32
if the type returned by the target couldn't represent all values.

This means the MVT::i32 case here is dead and can the logic can
be simplified.

Reviewed By: RKSimon

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

I made that type non-copyable in some cases in dc4f9f03

Break the if-else chain as every block returns, and remove the return at the end of the function as the else block means this was never hit

IntervalMap has seen type-punned arrays, AlignedCharArrayUnion and
std::aligned_union_t, with varying degrees of buggyness. Plain unions
have become quite powerful, so just try that instead.

Different shift amounts and multiuse tests

Test based off issues #51391 and #53867 - we're going to end up needing InstCombine + DAG variants of this fold as DAG can create BSWAP nodes as part of load folding

This is an extension of some of the tests mentioned in Issue #42019 - we might be able to use PSADBW to add+zext 4 x bytes to i64 that can then be reduced

Implements ADDS/SUBS 24-bit immediate optimization using the
MIPeepholeOpt pass. This follows the pattern:

Optimize ([adds|subs] r, imm) -> ([ADDS|SUBS] ([ADD|SUB] r, #imm0, lsl #12), #imm1),
if imm == (imm0<<12)+imm1. and both imm0 and imm1 are non-zero 12-bit unsigned
integers.

Optimize ([adds|subs] r, imm) -> ([SUBS|ADDS] ([SUB|ADD] r, #imm0, lsl #12), #imm1),
if imm == -(imm0<<12)-imm1, and both imm0 and imm1 are non-zero 12-bit unsigned
integers.

The SplitAndOpcFunc type had to change the return type to an Opcode pair so that
the first add/sub is the regular instruction and the second is the flag setting
instruction. This required updating the code in the AND case.

Testing:

I ran a two stage bootstrap with this code.
Using the second stage compiler, I verified that the negation of an ADDS to SUBS
or vice versa is a valid optimization. Example V == -0x111111.

Reviewed By: dmgreen

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

We have some duplicate patterns between the AArch64ISD::UMULL (/SMULL)
and the int_aarch64_neon_umull (/smull) intrinsics. They did not
replicate all the patterns though, leaving some gaps on instructions
like umlal2 from codegen. This commons all the patterns by converting
all int_aarch64_neon_umull intrinsics to UMULL nodes and removing the
duplicate for umull/smull intrinsics, so that all instructions go
through the same tablegen pattern.

This improves some of the longer-than-legal mla patterns, helping them
replace ext with umlal2.

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

This patch updates the cmake options suggested when cross compiling. This should fix [#52819](https://github.com/llvm/llvm-project/issues/52819).

Brad King (Member of CMake) says:

The linked [CMAKE_CROSSCOMPILING](https://cmake.org/cmake/help/v3.22/variable/CMAKE_CROSSCOMPILING.html) documentation says:

This variable will be set to true by CMake if the `CMAKE_SYSTEM_NAME` variable has been set manually (i.e. in a toolchain file or as a cache entry from the cmake command line).

It is not meant to be set by project code or toolchain files. It is always set automatically. Don't put `set(CMAKE_CROSSCOMPILING ON)` anywhere in your code.

`CMAKE_CROSSCOMPILING` indicates only whether `CMAKE_SYSTEM_NAME` was set by the user/project/toolchain-file instead of by CMake.

In LLVM project, `CMAKE_CROSSCOMPILING` is used to determine whether to execute some tests on the host machine.

LLVM needs to use another method for that. `CMAKE_CROSSCOMPILING` is not a reliable indicator of whether produced binaries will run on the host, and does not claim so in its documentation. If one sets `CMAKE_SYSTEM_NAME` to Linux in a toolchain file, and builds on a Linux host, that doesn't mean the target architecture or minimum glibc version is the same.

Reviewed By: rengolin

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

Otherwise it becomes asymmetric in the types it accepts.

I think the i32 in the pattern prevents this from matching on RV64,
but using IsRV32 is safer.

Add tests for RV64 to make sure we don't print zip or unzip
because we incorrectly picked ZIP_RV32/UNZIP_RV32.

If the "reciprocal-estimates" attribute is present and it doesn't
contain "all", "none", or "default", we previously crashed on f16
operations.

This patch addes an 'h' suffix' to prevent the crash.

I've added simple tests that just enable the estimate for all
vec-sqrt and one test case that explicitly tests the new 'h' suffix
to override the default steps.

There may be some frontend change needed to, but I haven't checked
that yet.

Reviewed By: pengfei

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

This patch adds assemblyFormat for omp.parallel operation.

Some existing functions have been altered to fit the custom directive
in assemblyFormat. This has led to their callsites to get modified too,
but those will be removed in later patches, when other operations get
their assemblyFormat. All operations were not changed in one patch for
ease of review.

Reviewed By: Mogball

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

The code was considering shifts by an about larger than the number of
bits in the original VT to be out of range. Shifts exactly equal to
the original bit width are also out of range.

I don't know how to test this. DAGCombiner should usually fold this
away. I just noticed while looking for something else in this code. The
llvm-cov report shows that we don't have coverage for out of range shifts here.

Reviewed By: arsenm

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

According to https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#atomic-memory-access-instructions,
the operands sequence of am* instructions should be "rd, rk, rj"
but not "rd, rj, rk". Sorry for this typo in initial patches.

Reviewed By: xen0n, MaskRay

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

After https://reviews.llvm.org/D119667, <algorithm> is no longer
transitively included from various headers. This patch adds the
<algorithm> include into gwp_asan.

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

After https://reviews.llvm.org/D119667, <algorithm> is no longer
transitively included from various headers. This patch adds the
<algorithm> include into scudo.

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

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