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

This reverts commit 86b5e256.

This wasn't supposed to be commited yet

getShiftAmountTy will return MVT::i32 if the shift amount
coming from the target's getScalarShiftAmountTy can't reprsent
all possible values. That should eliminate the need to use the
pointer type which is what we do when LegalTypes is false.

Reviewed By: arsenm

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

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.

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

This reverts commit 3a6be124.  This appears to have caused a stage2 build failure: https://lab.llvm.org/buildbot/#/builders/168/builds/4813

Will investigate further on Monday and recommit.

Reviewed By: bixia

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

D118577: the 0.1~1.1% .strtab size reduction does not justify the 3~6%
link time increase. Just remove it even for -O2. release/14.x
has D118577 and the release note mentioned that this may be removed.

Fix https://github.com/ClangBuiltLinux/linux/issues/1578
caused by D118577 (empty string not in stringMap).

This patch defines the SBDebugger::eBroadcastBitProgress enum in the SWIG
interface and exposes the SBDebugger::{GetProgressFromEvent,GetBroadcaster}
methods as well.

This allows to exercise the API from the script interpreter using python.

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



Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

Now that we use dedicated serialize and deserialize methods in order to
ensure consistency across big and small endian systems. The packed
qualifier on the Frame struct can be removed.

Reviewed By: davidxl, tejohnson

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

This was constraining the stale Info.Callee MO instead of the one we
copied into the MI.
In addition, with c8b8c8e9, when there's an attachedcall, the
Callee is at position 1 rather than 0.

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

These routines will need to be specialized a lot more based on value types,
index types, pointer types, and permutation/dimension ordering. This is a
careful first step, providing some functionality needed in PyTACO bridge.

Reviewed By: bixia

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

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

The problem can be shown from the newly added test case.
There are two invocations to MemorySSAUpdater::moveToPlace, and the
internal data structure VisitedBlocks is changed in the first
invocation, and reused in the second invocation. In between the two
invocations, there is a change to the CFG, and MemorySSAUpdater is
notified about the change.

Reviewed By: asbirlea

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