This seems to be an issue currently where there are nested/chained GEP/BitCast Pointers.
The patch generates a new GEP for the wider load to avoid dominance problems.

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

For small fixed-length vector copies like
vsetivli   zero, 2, e16, m1, ta, ma
vle16.v    v8, (a0)
vse16.v    v8, (a1)

We can scalarize them if the total vector size < XLEN:
lw a0, 0(a0)
sw a0, 0(a1)

This patch adds a DAG combine to do so, reusing much of the existing
logic in https://reviews.llvm.org/D150717

Reviewed By: reames

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

Reviewed By: reames

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

Only check for overflow on the min/max values, don't also check
for predicates in addition to that.

Make it clear that the leading/trailing zeros handling is only
relevant for the unknown LHS case, which is a fast path to avoid
the full shift amount loop in cases where it would not produce
better results.

I removed the conflict check from computeKnownBitsFromShiftOperator()
in D150648 assuming that this is now handled on the KnownBits side.
However, the nsw handling is still inside ValueTracking, so we
still need to handle conflicts there. Restore the check closer to
where it is relevant.

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

After 3a223f1e, it's no longer
necessary to put the users into a vector. We can directly iterate
them instead.

And make sure udiv() Exact does not produce conflicts.

This fixes #62880

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

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

Reviewed By: nikic

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

This also allows us to peel loops with a `select`:
```
for (int i = 0; i <= N; ++i);
  f3(i == 0 ? a : b); // select instruction
```
into:
```
f3(a); // peel one iteration
for (int i = 1; i <= N; ++i)
  f3(b);
```

Reviewed By: nikic

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

conditions

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

Fixes the issue reported at https://github.com/llvm/llvm-project/commit/4b8320868c9e32d1448c81ca76dba2a6b9f374cd#commitcomment-114671248.

The extractvalue instructions may still be used by the calling code
in some cases. Rather than trying to figure out which extracts are
safe to remove and which aren't, add them to the worklist so they
will get DCEd by the main loop.

With this, the body of CannotBeNegativeZero can be dropped.

This doesn't mean what I thought it meant and is an optimization
hint flag.

Close https://github.com/llvm/llvm-project/issues/62796.

Previously, we didn't serialize the evaluated result for VarDecl. This
caused the compilation of template metaprogramming become slower than
expect. This patch fixes the issue.

This is a recommit tested with asan built clang.

This patch implements SROA interfaces for MemRef, up to a given fixed
size.

Reviewed By: gysit, Dinistro

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

D151036 adds an assertions that prohibits iterating over sub- and
super-registers of a null register. This is already the case when
iterating over register units of a null register, and worked by
accident for sub- and super-registers.

Reviewed By: foad

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

MSVC has a `__cpuidex` function implemented to call the underlying cpuid
instruction which accepts a leaf, subleaf, and data array that the output
data is written into. This patch adds this functionality into clang
under the cpuid.h header. This also makes clang match GCC's behavior.
GCC has had `__cpuidex` in its cpuid.h since 2020.

Reviewed By: craig.topper

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

This reverts commit c0d6f85e. The asan
bot detected a memory leak after this patch. Revert it for now.

The type traits parts are moved to a type_traits detail header.
This was discovered while working on modules.

Reviewed By: #libc, ldionne

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

Clang has been updated to support C++26, this adds the same support for
libc++. At the moment C++23 and C++26 are identical. During the next
plenary in June the first C++26 papers will be voted on.

Note like Clang this patch uses C++26 is the internal part and C++2c in
the user visible part.

Depends on D150795

Reviewed By: ldionne, #libc

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

This reverts commit 72ab89e3.

Reverted due to bots failures e.g.
https://lab.llvm.org/buildbot/#/builders/139/builds/41339.

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

I stumbled upon the `operator new` and `operator new[]` tests while
investigating an issue with `operator new` when exceptions are disabled,
and I realized that our test coverage was incomplete. This patch refactors
all the `operator new` and `operator new[]` tests to add consistency and
better coverage for scenarios in which it should be possible to override
an operator indirectly by defining another one (for example new(size_t, nothrow)
should use new(size_t) if it has been provided).

This is intended to be a NFC setting up the terrain for some refactoring
work and bug fix in operator new.

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

In D148197, we have made `defvar` statement able to refer to class
template arguments. However, the priority of class/multiclass
template argument is higher than variables defined by `defvar`, which
is a little counterintuitive.

In this patch, we unify the priority of variables. Each pair of
braces introduces a new scope, which may contain some additional
variables like template arguments, loop iterators, etc. We can
define local variables inside this scope via `defvar` and these
variables are of higher priority than additional variables. This
means that `defvar` will shadow additional variables with the same
name. The scope can be nested, and we use the innermost variable.

This make variables defined by `defvar` prior to class/multiclass
template arguments, loop iterators, etc. The shadow rules now are:

* `V` in a record body shadows a global `V`.

* `V` in a record body shadows template argument `V`.

* `V` in template arguments shadows a global `V`.

* `V` in a `foreach` statement list shadows any `V` in surrounding record or global scopes.

Reviewed By: tra

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

The method is marked for deprecation. Delete the method and move all of
its consumers to use the DomTreeUpdater version.

Reviewed By: foad

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

The bot notes a warning-converted-error for the dangling pointer. And
the patch fixes that.

The problem was that the LevelIndentTracker remembered
the indentation level of previous deeper levels when
leaving a scope. Afterwards, when it entered again a
deeper level, it blindly reused the the previous
indentation level. In case of the --lines option
configured such that the previous deeper level was not
formatted, that previous level was whatever happened
to be there in the source code. The formatter simply
believed it.

This is fixed by letting the LevelIndentTracker forget
the previous deeper levels when stepping out of them
(=> change in LevelIndentTracker::nextLine()).
Note that this used to be the case until LLVM 14.0.6,
but was changed in
https://github.com/llvm/llvm-project/issues/56352 to
fix a crash. Our commit here essentially reverts that
crash fix. It seemed to have been incorrect. The proper
fix is to set the AnnotedLine::Level of joined lines
correctly (=> change in LineJoiner::join()).

See
https://github.com/llvm/llvm-project/issues/59178#issuecomment-1542637781
for some more details.

Fixes #58464.
Fixes #59178.

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

Close https://github.com/llvm/llvm-project/issues/62796.

Previously, we didn't serialize the evaluated result for VarDecl. This
caused the compilation of template metaprogramming become slower than
expect. This patch fixes the issue.

[LegalizeType][X86] Support WidenVecRes_AssertZext and SplitVecRes_AssertZext for ISD::AssertZext during LegalizeType procedure

Reviewed By: craig.topper

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

This information helps to avoid considering cloning for blocks with indirect branches.

Reviewed By: jhenderson

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