The `v` (`frame variable`) command can directly access ivars/fields of `this` or `self`.
Such as `v field`, instead of `v this->field`. This change relaxes the criteria for
finding `this`/`self` variables.

There are cases where a `this`/`self` variable does exist, but up to now the `v` command
has not made use of it. The user would have to explicitly run `v this->field` or
`self->_ivar` to access ivars. This change allows such cases to also work (without
explicitly dereferencing `this`/`self`).

A very common example in Objective-C (and Swift) is weakly capturing `self`:

```
__weak Type *weakSelf = self;
void (^block)(void) = ^{
   Type *self = weakSelf; // Re-establish strong reference.
   // `v _ivar` should work just as well as `v self->_ivar`.
};
```

In this case, `self` exists but `v` would not have used it. With this change, the fact
that a variable named `self` exists is enough for it to be used.

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

Reviewed By: lntue

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

Right now the bindings assume that all DenseElementsAttrs correspond to tensor values,
making it impossible to create vector-typed constants. I didn't want to change the API
significantly, so I opted for reusing the current signature of `.get`. Its `type` argument
now accepts both element types (in which case `shape` and `signless` can be specified too),
or a shaped type, which specifies the full type of the created attr (`shape` cannot be specified
in that case).

Reviewed By: ftynse

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

This patch adds the predicate as additional operand to VPReplicateRecipe
during initial construction. The predicated recipes are later moved into
replicate regions. This simplifies constructions and some VPlan
transformations, like fixed-order recurrence handling.

It also improves codegen in some cases (e.g. for in-loop reductions),
because the recipes remain in the same block.

Reviewed By: Ayal

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

Reduce the default value of `dwim-print-verbosity` to `eDWIMPrintVerbosityNone`.

Users who wish to see the rewritten expression can set this setting manually. Not unlike
`interpreter.expand-regex-aliases`.

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

The AIX linker does not support linking against libc++ if it exports symbols are redefined within compiled code.

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

Polly's internal vectorizer is not well maintained and is known to not work in some cases such as region ScopStmts. Unlike LLVM's LoopVectorize pass it also does not have a target-dependent cost heuristics, and we recommend using LoopVectorize instead of -polly-vectorizer=polly.

In the future we hope that Polly can collaborate better with LoopVectorize, like Polly marking a loop is safe to vectorize with a specific simd width, instead of replicating its functionality.

Reviewed By: grosser

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

A pointer dereference was added (D141302) above an assert that checks
whether the pointer is null. This commit moves the assert above the
dereference and transforms it into an llvm_unreachable to better express
the intent that certain switch cases should never be reached.

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

The one caller bitcasted the uint32_t to float anyway.

Clang wants to enable this flag by default, but libc++ isn't working with it yet.

Reviewed By: Mordante, #libc, #libc_abi, EricWF

Spies: libcxx-commits, arichardson

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

This reverts commit 9b9d0811.
(Accepted by Jon https://reviews.llvm.org/D118493#4178250)

libc++, libc++abi, libunwind, and compiler-rt don't add the extra DT_RUNPATH,
it's strange for OpenMP to diverge.
Some build systems want to handle DT_RUNPATH themselves (e.g.
CMAKE_INSTALL_RPATH). Some distributions (e.g. Fedora) have policies against
DT_RUNPATH and the default DT_RUNPATH for OpenMP is causing trouble.

For users who don't want to specify rpath by themselves,
https://clang.llvm.org/docs/UsersManual.html#configuration-files
can be used to specify the default rpath, e.g.
specify -frtlib-add-rpath or -Wl,-rpath in bin/clang.cfg

This patch resolves suboptimal code generation reported by https://github.com/llvm/llvm-project/issues/60571 .

DAGCombiner currently converts `(x or/xor const) + y` to `(x + y) + const` if this is valid.
However, if `.. + const` is broken down into a sequences of adds with carries, the benefit is not clear, introducing two more add(-with-carry) ops (total 6) in the case of the reported issue whereas the optimal sequence must only have 4 add(-with-carry)s.

This patch resolves this issue by allowing this conversion only when (1) `.. + const` is legal or promotable, or (2) `const` is a sign bit because it does not introduce more adds.

Reviewed By: RKSimon

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

As discussed in D145428, the memprof_init_is_running check can be moved
to the end of the initialization routine to avoid intercepting
allocations during initialization. Also, the memprof_init_done flag can
be removed and replaced with memprof_inited. Finally, memprof_inited can
also be moved to the end of the method.

Tested on the existing check-memprof tests; memprof profile collection
succeeded on a large internal workload.

Reviewed By: tejohnson

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

Reviewed By: sivachandra

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

Masked variants of UNPCKLPD, UNPCKHPD, and PERMILPS were missing and
be transformed with the same logic as their non-masked counterparts.

Reviewed By: RKSimon

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

Use this to handle new transform: `{v}unpck{l|h}pd` -> `{v}shufps`. We
need the sched information here as `{v}shufps` is 1 more byte of code
size, so we only want to make this transformation if `{v}shufps` is
actually faster.

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

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

This only matters for types larger than i64, and is consistent with
the code for RecurKind::And which also creates all 1s.

We don't have any tests for UMin or And with types larger than i64.

There are a couple bugs in the current support for this:
-We do all the parsing in single precision so any value less than or
 equal to the minimum fp32 is accepted as the minimum value for f64.
-To support fp16 minimum value, getLoadFP32Imm has a special case, but
 that causes a miscompile in CodeGen.

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

Instead of converting to FP value, store them as Index using an
immediate operand.

Do the same for the explicit index form.

This avoids using the FP32 version of these special values as the
representation for fli.h and fli.d. inf/nan aren't so bad, but
"min" is problematic as the current implementation allows fli.d and
fli.h to accept the decimal version of the fp32 minimum value. I
will submit another patch to fix that.

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

The support for enabling and disabling certain architectures for the
OpenMP device RTL is different between AMD and Nvidia. This patch
updates the logic to make it common. This supports the `auto` format
more generally via the `nvptx-arch` and `amdgpu-arch` options. (These
are not availible at CMake time without a runtimes build, or another
install somewhere. But that only prevents users from using auto).

Reviewed By: ye-luo

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

These intrinsics are equivalent to the regular @llvm.riscv.vssegNF
intrinsics, only they accept fixed length vectors in their overloaded
types: The regular intrinsics only operate on scalable vectors.
These intrinsics convert the fixed length vectors to scalable ones, and
then lower it on to the regular scalable intrinsic.

This mirrors the intrinsics added in 0803dba7
This will be used in a later patch with the Interleaved Access pass.

Reviewed By: craig.topper

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

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

The module std does not provide c-types in the global namespace. This
means all these types need to be fully qualified. This is a first step
to convert them by using sed.

Since this is an automated conversion other types like uint64_t are kept
as is.

Note that tests in the directory libcxx/test/std/depr/depr.c.headers
should not be converted automatically. This requires manual attention,
there some test require testing uint32_t in the global namespace. These
test should fail when using the std module, and pass when using the
std.compat module.

A similar issue occurs with atomic, atomic_uint32_t is specified as
  using atomic_uint32_t = atomic<uint32_t>; // freestanding
So here too we need to keep the name in the global namespace in the
tests.

Reviewed By: ldionne, #libc

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

I've pulled this change from D145404 to land in isolation because
I'm concerned the code might be more important than the test
coverage might suggest (NOTE: the code has no test coverage).

This reverts commit a9356a51.

Without the definition, build fails on AArch64 with

> error: 'AT_HWCAP2' undeclared (first use in this function);
> did you mean 'AT_HWCAP'?

with old Glibc versions.

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

Glibc provides the argp_parse() function for parsing command line
arguments [1].

Indicate that argc/argv are read from and arg_index is written to.
Strictly speaking, we also need to indicate that argp is read from,
but this would require describing its layout, and most people use a
static initializer there, so it's not worth the effort.

[1] https://www.gnu.org/software/libc/manual/html_node/Argp.html

Reviewed By: vitalybuka

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

When building compiler-rt builtins for x86_64 they library will by default
also be built for i386. We unconditionally add the Float16 compile flags
since the check for Float16 support will be done using x86_64 compiler
flags, but i386 does not actually support it. Fix this by moving the
COMPILER_RT_HAS_FLOAT16 and COMPILER_RT_HAS_FLOAT16 checks to a
per-target-architecture check inside the loop (using
`check_c_source_compiles` and `cmake_{push,pop}_check_state`).

Many of the checks in the builtin-config-ix file should probably also be
changed to per-target-arch checks, but so far only the Float16 one has
caused issues. This is an alternative to D136044 which added a special case
for i386 FreeBSD.

Fixes: https://github.com/llvm/llvm-project/issues/57224
Differential Revision: https://reviews.llvm.org/D145237

The last user was ProcessMessage, which has itself been removed.

Reviewed By: emaste

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

This check flags code which uses `_LIBCPP_STD_VER` the wrong way, or tries to use `__cplusplus`. It flags cases where we use `_LIBCPP_STD_VER >` instead of `_LIBCPP_STD_VER >=` and where wrong values are used (e.g. `_LIBCPP_STD_VER >= 24`).

Reviewed By: ldionne, #libc

Spies: libcxx-commits

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

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

This implements the atand intrinsic by performing a multiplication
by 180/pi to the result of a call to atan inline.

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

Reviewed By: mikhail.ramalho

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

This reverts commit fd8c9ef2.

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

In the same vein as https://reviews.llvm.org/D141553
Enable the feature globally to ensure layering and catch circular dependencies
(https://llvm.org/docs/CodingStandards.html#library-layering).

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

The last use of these was removed in cd443398.

Reviewed By: emaste

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