[PowerPC] Fallback to base's implementation of shouldExpandAtomicCmpXchgInIR and shouldExpandAtomicCmpXchgInIR

If we can't decide `shouldExpandAtomicCmpXchgInIR` or `shouldExpandAtomicCmpXchgInIR` in PPC's implementation after https://reviews.llvm.org/rGb9c3941cd61de1e1b9e4f3311ddfa92394475f4b, resort to base's implementation.

This fixes internal build of OpenMP which uses atomic operations on float.

Reviewed By: jsji

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

This avoids the compiler warning on Darwin where that function is unused.

The pattern we match is (sext_inreg (assertzexti32 (fp_to_uint)), i32). If
the assertzexti32 has an additional user we'll end up emitting
an fcvt.wu and an fcvt.lu.

This can happen if the original fp_to_uint before type legalization
has one user that causes a sext_inreg to be emitted and one that
doesn't.

Based on de448c0a.

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

I don't think the stat subsystem was ever used since tsan
development in 2012. But it adds lots of code and this
effectively dead code needs to be updated if the runtime
code changes, which adds maintanance cost for no benefit.
Normal profiler usually gives enough info and that info
is more trustworthy.
Remove the stats subsystem.

Reviewed By: vitalybuka

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

This does ensure `InformationCache::getPotentiallyReachable` will not
crash/assert on instructions from different functions but simply return
that one is reachable, which is conservatively correct.

As with other patches before, the simplification callback interface
requires us to go through the Attributor::getAssumedSimplified API first
before we recurs.

It is unclear if the problem can be explicitly tested with our current
infrastructure.

We first simplify the operands of a compare and then reason on the
simplified versions, e.g., with AANonNull.

This does improve the simplification capabilities but also fixes a
potential problem that has not yet been observed by simplifying the
operands first.

Undo 15c5701c and update check lines.

Add pragma line so that errors messages point to the actual
source files rather than to the concatenated gotsan.cpp.

Reviewed By: vitalybuka, melver

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

The test is not wrong nor is the current main broken, it just an
interplay issue. Check lines will be updated in shortly.

A byval argument is a different value in the caller and callee, we
cannot propagate the information as part of AAValueSimplify. Users that
want to deal with byval arguments need to specifically perform the
argument -> call site step. We do not do this for now.

This patch introduces AAPointerInfo which tracks the uses of a pointer
and places them in "bins" based on their offset from the base and access
size.

As with other AAs, any pointer can be tracked but it is up to the user
to make sense of the results. The user in this patch is AAValueSimplify
and AAPotentialValues which both utilize AAPointerInfo to determine the
value of a load. For now, this is restricted to loads of allocas and
internal globals. Through the use of AAPointerInfo and the "bins" we can
track struct members separately. The users also know that storing only
zeros (at unknown indices) will result in loading only 0 (from unknown
indices). Other than that, the users are flow and context insensitive
(for now).

To deal with the "bins" more easily, AAPointerInfo provides a
forallInterfearingAccesses that applies a callback on all accesses
that might interfere with a given load or store.

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

As a first step to simplify loads we only handle `null` and `undef`
underlying objects, as well as objects that have the load as a single user.
Loads of those values can be replaced by the initializer, if any.
Proper reasoning is introduced in a follow up patch

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

We did not properly use SPMDCompatibilityTracker in various places.
This patch makes sure we look at the validity properly and also fix
the state if we can.

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

This reverts commit 1d3e77e7 as
some buildbots seem to be unable to obtain the target
powerpc64le-unknown-linux-gnu.

Reviewed By: tianshilei1992

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

This macro can be used to define tag variables for use with jit-dispatch.

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

This reverts commit 321b2bef.

`for (BindIR *p = &opcodes[0]; p->opcode != BIND_OPCODE_DONE; ++p) {` has a heap-buffer-overflow with test/MachO/bind-opcodes.

The synchronization of task loop misses hidden helper tasks, causing segmentation
fault reported in https://bugs.llvm.org/show_bug.cgi?id=50002.

Reviewed By: ye-luo

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

This avoids rerunning it a few times.

An extra test case added for the builtin __LDARX.

Differential revision: https://reviews.llvm.org/D105926

I don't understand what this is going for, and haven't found an analog
in DAG code. No tests fail with this removed.

Revert D105519 "[WebAssembly] Deduplicate imports of the same module name, field name, and type" and its followup

This reverts commit 4ae575b9 and 9b965b37.

There is an use-of-uninitialized-value bug in the `else` branch in ImportSection::addImport.

Currently the NPVTX work function is marked volatile. This prevents some
optimizations from using this value.

Reviewed By: jdoerfert

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

See https://reviews.llvm.org/D105905 for context.

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

We've been forgetting to add those to most of the <ranges> review.
To avoid forgetting in the future, I added an item in the pre-commit
checklist.

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

Implement pass 3 of bind opcodes from ld64 (which supports both 32-bit and 64-bit).
Pass 3 implementation condenses BIND_OPCODE_DO_BIND_ADD_ADDR_ULEB opcode
to BIND_OPCODE_DO_BIND_ADD_ADDR_IMM_SCALED.  This change is already behind an
O2 flag so it shouldn't impact current performance. I verified ld64's output with x86_64 LLD
and they were both emitting the same optimized bind opcodes (although in a slightly different
order). Tested with arm64_32 LLD and compared that with x86 LLD that the order of the bind
opcodes are the same (offset values are different which should be expected).

Reviewed By: int3, #lld-macho

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

Allow arbitrary strides, and make sure we return the correct result when
the backedge-taken count is zero.

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

Only memref with identity layout map is supported for now.

Reviewed By: mravishankar

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

Wrap semantics are subtle when combined with multiple exits.  This has caused several rounds of confusion during recent reviews, so try to document the subtly distinction between when wrap flags provide <u and <=u facts.

Reviewed By: asbirlea

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