Reviewed By: SixWeining

Pull Request: https://github.com/llvm/llvm-project/pull/92374

If an ifunc has local linkage, do not add it into ref edges and mark its
referencer (a function or global variable) not eligible for import. An
ifunc doesn't have summary and ThinLTO cannot promote it. Importing the
referencer may cause linkage errors.

To reference a similar fix, https://reviews.llvm.org/D158961 marks
callers of local ifunc not eligible for import to fix
https://github.com/llvm/llvm-project/issues/58740

The test expectations are otherwise affected by the underlying type of size_t.

[TableGen] Use LessRecord() for the sort in getAllDerivedDefinitions instead of re-implementing it. NFC

Record::getName already returns a StringRef. When this code was
originally written getName returned const std::string &.

In late 2021, both Intel and AMD finally documented that every
AVX-capable CPU has always been guaranteed to execute aligned 16-byte
loads/stores atomically, and further, guaranteed that all future CPUs
with AVX will do so as well.

Therefore, we may use normal SSE 128-bit load/store instructions to
implement atomics, if AVX is enabled.

Per AMD64 Architecture Programmer's manual, 7.3.2 Access Atomicity:

> Processors that report [AVX] extend the atomicity for cacheable,
> naturally-aligned single loads or stores from a quadword to a double
> quadword.

Per Intel's SDM:

> Processors that enumerate support for Intel(R) AVX guarantee that the
> 16-byte memory operations performed by the following instructions will
> always be carried out atomically:
> - MOVAPD, MOVAPS, and MOVDQA.
> - VMOVAPD, VMOVAPS, and VMOVDQA when encoded with VEX.128.
> - VMOVAPD, VMOVAPS, VMOVDQA32, and VMOVDQA64 when encoded with
>   EVEX.128 and k0 (masking disabled).

This was also confirmed to be true for Zhaoxin CPUs with AVX, in
https://gcc.gnu.org/PR104688

Due to how `CodeGenFunction::EmitTrapCheck` is implemented
`SanitizerHandler` with numeric value 0x19 needs to be reserved because
`-fbounds-safety` generates trap instructions with that value embedded
in the trap instructions for x86_64 and arm64 just like for UBSan traps.

** x86_64 **

```
ud1l   0x19(%eax), %eax
```

** arm64 **

```
brk    #0x5519
```

To avoid upstream Clang and AppleClang diverging their ABIs for
`-fbounds-safety` the slot is being reserved in this patch.

`SanitizerHandler::BoundsSafety` currently has no uses in the code but
uses will be introduced when the CodeGen side of `-fbounds-safety`'s
implementation is upstreamed.

rdar://126884014



Co-authored-by: Dan Liew <dan@su-root.co.uk>

this is the dual of ArrayMinCount. I saw that I needed it but it didn't
exist yet

Fixes #91312.

Don't perform the transform if the alias may be replaced at link time.

This solves some ambuguity introduced in P0522 regarding how
template template parameters are partially ordered, and should reduce
the negative impact of enabling `-frelaxed-template-template-args`
by default.

When performing template argument deduction, a template template
parameter
containing no packs should be more specialized than one that does.

Given the following example:
```C++
template<class T2> struct A;
template<template<class ...T3s> class TT1, class T4> struct A<TT1<T4>>; // #1
template<template<class    T5 > class TT2, class T6> struct A<TT2<T6>>; // #2

template<class T1> struct B;
template struct A<B<char>>;
```

Prior to P0522, candidate `#2` would be more specialized.
After P0522, neither is more specialized, so this becomes ambiguous.
With this change, `#2` becomes more specialized again,
maintaining compatibility with pre-P0522 implementations.

The problem is that in P0522, candidates are at least as specialized
when matching packs to fixed-size lists both ways, whereas before,
a fixed-size list is more specialized.

This patch keeps the original behavior when checking template arguments
outside deduction, but restores this aspect of pre-P0522 matching
during deduction.

---

Since this changes provisional implementation of CWG2398 which has
not been released yet, and already contains a changelog entry,
we don't provide a changelog entry here.

This is part of the fixes to address #57353

https://reviews.llvm.org/D133845

Pull Request: https://github.com/llvm/llvm-project/pull/92334

Currently in Core dumps, the entire pthread is copied, including the
unused space beyond the stack pointer. This causes large amounts of core
dump inflation when the number of threads is high, but the stack usage
is low. Such as when an application is using a thread pool.

This change will optimize for these situations in addition to generally
improving the core dump performance for all of lldb.

Summary:
A runtime library should not have global constructors. Everything is now
expected to go through the init methods. This patch ensures that global
constructors will not accidentally be introduced.

We currently don't support passing files and don't need frontend involvement either.

Split of https://github.com/llvm/llvm-project/pull/90835
Adds support for `TransferReadOfExtractSliceOpFolder` when the
`TransferReadOp` is inside a `MaskOp`.

https://github.com/llvm/llvm-project/pull/71328 refactored
`llvm-profdata.cpp` to use subcommands (which is super nice), but left
many unused `argv` variables. This opts to use `ProgName` where
necessary, and removes `argv` otherwise.

This patch adds comments for writeMemProf{V0,V1,V2} in a
version-specific manner.  The mostly repetitive nature of the comments
is somewhat unfortunate but intentional to make it easy to retire
older versions.

Without this patch, the comment just before writeMemProf documents the
Version1 format, which is very confusing.

Summary:
This was written before we had the address space helpers. Using
numerical address spaces is bad so this should be removed.

Summary:
Previously, the R&R support was global state initialized by a global
constructor. This is bad because it prevents us from adequately
constraining the lifetime of the library. Additionally, we want to
minimize the amount of global state floating around.

This patch moves the R&R support into a plugin member like everything
else. This means there will be multiple copies of the R&R implementation
floating around, but this was already the case given the fact that we
currently handle everything with dynamic libraries.

LLVM is built with C++17, where left shift of any negative value is still UB.
Detected with UBSan on the buildbot.

This reverts commit 0647d103.

Added a unittest demonstrating Error -> Expected<T> forwarding.

The code seems easier to read if it's centered on what the user wants rather than combinations of whatever internal variables.

Namely, we specify that `auto` in a lambda parameter is a C++14
extension in the error message, which now reads:

`'auto' not allowed in lambda parameter before C++14`

This does not change the behavior for `decltype(auto)` and `__auto_type`
though.

---------

Co-authored-by: cor3ntin <corentinjabot@gmail.com>

[clang] CTAD alias: Emit a more descriptive diagnostic message when is_deducible  constraint is evaluated to false. (#92389)

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

The dictionary entry `=""` is invalid.

When the argument passed to `ASTContext::getUnconstrainedType` is an
unconstrained `AutoType`, will return the argument unchanged. However,
when called with a constrained `AutoType`, an unconstrained,
non-dependent `AutoType` will be returned even if the argument was
dependent. Consider the following:
```
template<typename T>
concept C = sizeof(T) == sizeof(int);

template<auto N>
struct A;

template<C auto N>
struct A<N>; // error: class template partial specialization is not more specialized than the primary template
```
When comparing the template parameters for equivalence,
`ASTContext::getUnconstrainedType` is used to remove the constraints per
[temp.over.link] p6 sentence 2. For the template
parameter `N` of the class template, it returns a dependent `AutoType`.
For the template parameter `N` of the class template partial
specialization, it returns a non-dependent `AutoType`. We subsequently
compare the adjusted types and find they are not equivalent, thus we
consider the partial specialization to not be more specialized than the
primary template per [temp.func.order] p6.2.2.

This patch changes `ASTContext::getUnconstrainedType` such that the
dependence of a constrained `AutoType` will propagate to the returned
unconstrained `AutoType`. This causes the above example to be correctly
accepted, fixing #77377.

This is valid as long as the sign of the wrap flag doesn't differ from
the sign of the `pred`.

Proofs: https://alive2.llvm.org/ce/z/35NsrR

NB: The online Alive2 hasn't been updated with `trunc nuw/nsw`
support, so the proofs must be reproduced locally.

Closes #87935

`(icmp ule/ult (add nuw X, Y), C)` implies both `(icmp ule/ult X, C)` and
`(icmp ule/ult Y, C)`. We can use this to deduce leading zeros in `X`/`Y`.

`(icmp uge/ugt (sub nuw X, Y), C)` implies `(icmp uge/uge X, C)` . We
can use this to deduce leading ones in `X`.

Proofs: https://alive2.llvm.org/ce/z/sc5k22

Closes #87180

The README.md is what users see when they look for the extension in the
Marketplace [1]. Right now, it's a mix of developer documentation (for
us) and user documentation. This commit moves the developer docs into
`docs` and the lldb website and refocuses the README on using the
extension.

[1] https://marketplace.visualstudio.com/items?itemName=llvm-vs-code-extensions.lldb-dap

This patch groups the three Memprof data structures into a struct
named IndexedMemProfData and teaches InstrProfWriter to use it.  This
way, we can pass IndexedMemProfData to writeMemProf and its helpers
instead of individual data structures.

As a follow-up, we can use the new struct in MemProfReader also.  That
in turn allows loadInput in llvm-profdata to move the MemProf data
into the writer context, saving a few seconds for a large MemProf
profile.

These tests are based on dap_server which runs locally. These tests
failed in case of Windows host and Linux target.

## Abstract

This pull request implements LWG3672: `common_iterator::operator->()`
should return by value. The current implementation specifies that this
function should return the underlying pointer by reference (`T*
const&`), but it would be more intuitive to return it by value (`T*`).

## Reference

- [Draft C++ Standard:
[common.iter.access]](https://eel.is/c++draft/common.iter.access)
- [LWG3672](https://cplusplus.github.io/LWG/issue3672)

Use https://github.com/llvm/vscode-lldb instead of the monorepo, for
consistency with the other two extensions (mlir, clangd).

Revert "[Clang][CWG1815] Support lifetime extension of temporary created by aggregate initialization using a default member initializer (#87933)"

This reverts commit 17daa204.

Multiple examples on the PR
https://github.com/llvm/llvm-project/pull/87933

show regressions, so reverting until they can be fixed in the followup.

Summary:
Forgot to remove these when I landed the initial patch, they are no
longer used.