After D134378, we started seeing crashes with incomplete types (in the
context of shared libraries).

When trying to print a `std::vector<int> &` with only debug info for a
declaration, we now try to use the formatter after D134378. With an
incomplete type, this somehow goes into infinite recursion with the
frames

```
lldb_private::ValueObject::Dereference
lldb_private::ValueObjectSynthetic::CreateSynthFilter
lldb_private::ValueObjectSynthetic::ValueObjectSynthetic
lldb_private::ValueObject::CalculateSyntheticValue
lldb_private::ValueObject::HasSyntheticValue
```

This has to do with `FrontEndWantsDereference` that some STL formatters
set, causing recursion between the formatter (which tries to dereference),
and dereferencing (which wants to know if there's a formatter to avoid dereferencing).

The reason this only started appearing after D134378 was because
previously with incomplete types, for names with `<`, lldb would attempt
to parse template parameter DIEs, which were empty, then create an empty
`ClassTemplateSpecializationDecl` which overrode the name used to lookup
a formatter in `FormattersMatchData()` to not include template
parameters (e.g. `std::vector<> &`). After D134378 we don't create a
`ClassTemplateSpecializationDecl` when there are no template parameters
and the name to lookup a formatter is the original name (e.g.
`std::vector<int> &`).

The code to try harder with incomplete child compiler types was added in
D79554 for ObjC purposes.

Reviewed By: labath

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

[X86] Synchronise scheduler classes of VPERM2F128/VBROADCASTF128/VEXTRACTF128/VINSERTF128 with I128 equivalents

znver1/znver2 has barely any difference in behaviour between the AVX1/2 variants of these instructions - it looks like it was a copy+paste mistake to miss the AVX2 integer domain instructions in the overrides.

Having said that the override numbers don't appear to match the numbers in the AMD 17h SoGs very well - for instance vperm2f128/vperm2i128 might be microcoded from the AMD sense of >3 uops, but it doesn't have a 100cy latency..... These will need to be further addressed.

When the bounds check attribute is true, the raw buffer load, store,
and atomic operations have well-defined behavior (returning 0 for
loads and ignoring stores) when the buffer access exceeds the bounds
of the memory being accessed.

Because of how LLVM currently implements these buffer operations (as
opaque intrinsics), the backend cannot optimize out this known
behavior and eliminate the memory operations. Therefore, use MLIR's
canonicalization system to eliminate these operations.

Reviewed By: nirvedhmeshram

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

We already do this for most cases, with the exception of instructions that
get expanded to function calls (e.g. for lowering operations on fp128
values), in which case we temporarily allocate a lazy-save buffer.

The code that is generated in this case, is however incorrect, as it seems
to pass an incorrect address for the TPIDR2 object to the ZA restore
function. By always allocating the lazy-save buffer once, we avoid this
issue entirely.

The cost is that we also allocate such a buffer when it is not
needed. We could fix that in a follow-up patch, where we remove the
lazy-save buffer when it isn't used.

Reviewed By: paulwalker-arm

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

TestVSCode_coreFile looks for an exe/core file in the same directory as the test. It first calls `realpath`, but I don't think it's necessary. Using `realpath` prevents this test from working when run as part of a build system that uses content-addressed-storage, i.e. all the files might all be symlinks in the same directory pointing to files in different directories elsewhere. If some amount of normalization is needed, maybe `os.path.normpath()` would be useful, although I wouldn't see why that's needed either.

(This is a fairly trivial patch, but I'm mailing it to see if there is a reason we need to keep `realpath`, and if so, if there's some other workaround we can do).

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

The AArch64 target now has the necessary support for strict fp, so
enable it in clang.

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

Couple of operation are expecting BoxType but can totally handle
ClassType as well. This patch updates couple of locations to support
BaseBoxType instead of BoxType only.

Reviewed By: jeanPerier, PeteSteinfeld

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

The flag ends with a `=`, so its name should end with `_eq`.
No behavior change.

The Assignment Tracking debug-info feature is outlined in this RFC:

https://discourse.llvm.org/t/
rfc-assignment-tracking-a-better-way-of-specifying-variable-locations-in-ir

Reviewed By: StephenTozer

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

This avoids a slow step after timing tidy checks for https://github.com/clangd/clangd/issues/1337

This is less plumbing and clutter in ClangdMain.cpp.
Having --check-lines imply completion was just about minimizing plumbing
I think, so make that explicit.

misc-const-correctness is so catastrophically slow that we need to block it
from running. But we need a way to detect this without breaking users first.

This is part of a plan to run only fast checks by default.
More details in  https://github.com/clangd/clangd/issues/1337

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

Reviewers: James Henderson, Esme Yi

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

These are a couple of test cases from 58441, showing LCSSA uses on
the IV increment. Part of D138404.

Various InstCombine tests to show diffs with the new
extractelement / select folding.

MemRef has been accepting a general Attribute as memory space for
a long time. This commits updates bufferization side to catch up,
which allows downstream users to plugin customized symbolic memory
space. This also eliminates quite a few `getMemorySpaceAsInt`
calls, which is deprecated.

Reviewed By: springerm

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

The -fconcepts-ts flag has been deprecated for 5 releases now, so just
remove it, concepts is supported in C++20 mode.

Reviewed By: RKSimon

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

Clang's lit.cfg.py reads this to add an "enable-shared" feature that
three of clang's lit tests use. Nothing else reads enable_shared, so
remove it from most lit.site.cfg.py.in files.

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

Libc++ tried accomodating systems that need to be able to define various
__need_FOO macros before including C library headers, however it does not
appear to be needed anymore in most cases. Indeed, glibc used to use that
system to conditionally provide definitions, however almost all instances
of these macros have been removed from glibc years ago.

I think the next step would be to also fix Clang's own builtin headers
to stop needing these macros.

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

resolve conflicts

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

Before this patch, the code enumerated `getCondFromBranch`, `getCondFromSETCC` and `getCondFromFromCMov` to get the condition code of a `MachineInstr`, and assigned the result to variable `OldCC` when `MI || IsSwapped || ImmDelta != 0` was satisfiled.

After this patch, the `if-else` structure is eliminated by using `getCondFromMI`. Since `OldCC` is only used when  `MI || IsSwapped || ImmDelta != 0`  is true, it is initialized with `getCondFromMI` directly outside the scope of `if` now.

Reviewed By: pengfei

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

Shift is 0 for all non comments, maybe even for comments. Don't add the
0 up to three times.

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

This sort of amends cdbe2968

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

Done by clang-format itself.

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

Original [RFC](discourse.llvm.org/t/rfc-primitive-ops-add-broadcastop-to-linalg/66313) defined `dimensions` as a map from input to init, but a discussion in reviews.llvm.org/D138291 concluded that it's more natural for `dimensions` to represent added dims. Also this way is more consistent with `linalg.reduce`.

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

We generate erroneous trace for a basic block if it does not have at least one
predecessor when MinInstr strategy is used. Currently only this strategy is
implemented, so we always have a wrong trace for any entry block. This results in
wrong instructions heights calculation and also leads to wrong critical path.

The described behavior is demonstrated on a simple test. It shows that early
if-conv pass makes wrong decisions due to incorrectly calculated critical path
lenght.

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