Peek through if we're extracting a non-zero'th subvector in an attempt to fold the extract into a lane-crossing shuffle

This also exposes a failure to fold extract_subvector(movddup(x),c) -> movddup(extract_subvector(x,c))

This patch adds typing of inequalities to the simplex. This is a cental part of the coalesce algorithm and will be heavily used in later coalesce patches. Currently, only the three most basic types are supported with more to be introduced when they are needed.

Reviewed By: arjunp

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

Perfect shuffle was introduced into PowerPC backend years ago, and only
available in big-endian subtargets. This optimization has good effects
in simple cases, but brings serious negative impact in large programs
with many shuffle instructions sharing the same mask.

Here introduces a temporary backend hidden option to control it until we
implemented better way to fix the gap in vectorshuffle decomposition.

Reviewed By: jsji

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

Extension to PR45974, unless we actual combine the target shuffles we shouldn't be generating temporary nodes as they may interfere with the one use checks in the shuffle recursions

Add an extra store to the test, to make sure the operations in the loop
cannot be optimized away after D118051.

These are unused by Clang, but Flang references them.

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.