The runtime initializes this.

This reverts commit b5cb91fc.

This commit causes expensive check fail:
https://lab.llvm.org/buildbot/#/builders/16/builds/41677.

The problem is happened when base class member field is used in target
region , the size is wrong, cause runtime to fail. Currently the size of
calculation is depended on index of field, since field is in base class,
the calculation is wrong.

According OpenMP 5.2 148:21:
If the target construct is within a class non-static member function,
and a variable is an accessible data member of the object for which the
non-static data member function is invoked, the variable is treated as
if the this[:1] expression had appeared in a map clause with a map-type
of tofrom.

One way to fix this is emitting code to generate this[:1] instead only
when class has any base class.

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

Previous attempt to restrict this test to x86 and aarch64 targets only didn't work.
So XFAIL this test while investigating to get the AIX bot back to green.

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

[libc++] Use _LIBCPP_HIDE_FROM_ABI_VIRTUAL instead of _LIBCPP_INLINE_VISIBILITY attribute on virtual function

Reviewed By: #libc, philnik, ldionne

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

The Xcode standalone build doesn't have the install-liblldb and
install-liblldb-stripped targets. Fix the resulting CMake error "Cannot
add target-level dependencies to non-existent target" by only adding the
dependency when the targets exist.

There's a bit of duplication in use of `common_input_iterator` as noted in
https://reviews.llvm.org/D141216.  Lift `common_input_iterator` into
`test_iterators.h`.

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

Implemented LSAN interface on HwasanThreadList and added os_id to __hwasan::Thread.

Reviewed By: vitalybuka

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

This follows the [[ https://discourse.llvm.org/t/rfc-promoting-the-loongarch-backend-from-experimental-to-official/67506/ | RFC ]].

Follow-on commits will add appropriate release notes changes etc.

Submit this now and in a minimal form so there is reasonable time before
16.0.0 is branched to resolve any issues arising from e.g. the backend
being exposed on different compiler/sanitizer setups.

The current builder for LoongArch is on the [[ https://lab.llvm.org/staging/#/builders/236 | staging area ]].

Reviewed By: jyknight, MaskRay, echristo, myhsu, tstellar, arsenm

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

Reviewed By: vitalybuka

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

This is part of effort in removing -enable-new-pm flag.
As a prat of this effort one of example passes SimplifyCFG must
be ported to new PM which will allow to remove the flag
calls from the tests that are using this pass.

Reviewed By: aeubanks

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

Fold them into their only callers, getRealMinVLen()/getArchMaxVLen().

It is unclear right now when these are needed so removing to discourage
misuse.

Between Zvl*b extensions, vector length command line options, and
vscale range, we have several ways to influence vector length. We
need to try to keep all code on the same page.

According to DWARF5 specification and gnu specification for DWARF4 the offset
entry in the CU/TU Index is 32 bits. This presents a problem when
.debug_info.dwo in DWP file grows beyond 4GB. The CU Index becomes partially
corrupted.

This diff adds manual parsing of .debug_info.dwo/.debug_abbrev.dwo to
reconstruct CU index in general, and TU index for DWARF5. This is a work around
until DWARF6 spec is finalized.

Next patch will change internal CU/TU struct to 64 bit, and change uses as
necessary. The plan is to land all the patches in one go after all are approved.

This patch originates from the discussion in: https://discourse.llvm.org/t/dwarf-dwp-4gb-limit/63902

Reviewed By: dblaikie

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

This helps print instructions with detached operands in the debugger.

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

Recent Android NDKs don't ship with libgcc

The Attributor has logic to run only on assumed live functions and this
is exposed to users now. OpenMP-opt will (mostly) ignore dead internal
functions now but run the same deduction as before if an internal
function is marked live.

This should lower compile time as we run on less code and delete more
code early on. For the full OpenMC module compiled with noinline and
JITed at runtime, we save ~25%, or ~10s on my machine during JITing.

When we collect and process allocations we did not verify the call
against the anchor scope / associated function. This should be done to
avoid processing calls multiple times and generally looking at calls not
in the AAs scope.

This is not tested well and needs to be revisited in the future.

This matches other tests and makes this test less sensitive

This reverts commit 1fbbf92e.

This resolves a recent regression introduced by a bug fix and allows us
to use dominating write information (formerly HasBeenWrittenTo
information) to skip potential interfering accesses.

Generally, there are two changes here:
1) If we have dominating writes they form a chain and we can look at the
   least one to minimize the distance between the write and the (read)
   access in question.
2) If such a least dominating write exists, we can ignore writes in
   other functions as long as they cannot be reached from code between
   this write and the (read) access in question.

We have all the tools available to make such queries and the positive
tests show the result. Note that the negative test from the bug fix is
still in tree and not affected.

As a side-effect, we can remove the (arbitrary) treshold now on the
number of interfering accesses since we do not iterate over dominating
ones anymore.

We can fold redundant Tosa::TransposeOp actions like identity tranpose/transpose(traspose).

Reviewed By: rsuderman

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

This patch enables sanitizer common unit tests for arm64 architecture only on apple devices.

It also lowers the expected compression ratio for 64 bit machines. Unsure of justification of 130. On apple arm64 we're seeing this number comeout to 128.6

rdar://101436019

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

Signed and unsigned minimum operations were missing from the Index
dialect and are needed to test integer range inference.

Reviewed By: Mogball

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

D135089 extracted the extui code into a helper, but used fromSigned
instead of fromUnsigned.

Reviewed By: Mogball, ThomasRaoux

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

UInt16 is included as a required TOSA type for basic
operations. Added support as a TOSA Tensor.

Reviewed By: NatashaKnk

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

This fixes a regression introduced by D127115 in test/CodeGen/PowerPC/store-forward-be64.ll

Reviewed By: RKSimon

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

Reviewed By: bkramer

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

This reverts commit e425a4c4 after the
memory leak has been fixed.

`import sys` is unused in `libcxx/utils/run.py`: remove it.

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

Support for these CMake variables has been a warning for a while now.  The
comment indicates to just remove the warning message entirely as anyone impacted
had to have update to new mechanisms in order to use `libc++`.  So, remove the
warning message.

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

Similar to https://reviews.llvm.org/D140896, this adds deduction guides for the
counterpart of `ArrayRef`: `MutableArrayRef`.  The update plan is the following:

1) Add deduction guides for `MutableArrayRef`.
2) Change uses in-tree from `makeMutableArrayRef` to use deduction guides
3) Mark `makeMutableArrayRef` as deprecated for some time before removing to
   give downstream users time to update.

The deduction guides are similar to those provided by the `makeMutableArrayRef`
function templates, except we don't need one explicitly from `MutableArrayRef`.

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

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

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