Reviewed By: ldionne, #libc

Spies: huixie90, eaeltsin, joanahalili, bgraur, alexfh, hans, avogelsgesang, augusto2112, libcxx-commits, mgorny

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

This one actually makes the test simpler, because lit doesn't have to
reconstitute a 32-bit little-endian value from individual bytes any
more: llvm-objdump is printing the desired 32-bit value in the first
place, so we can move straight on to doing the arithmetic on it.

This patch starts small, only detecting sequences of the form
<a, a+n, a+2n, a+3n, ...> where a and n are ConstantSDNodes.

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

Right now we silently overflow uint32_t for debug_indfo sections. Added a check
and error out.

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

Turning on opaque pointers has uncovered an issue with WPD where we currently pattern match away `assume(type.test)` in WPD so that a later LTT doesn't resolve the type test to undef and introduce an `assume(false)`. The pattern matching can fail in cases where we transform two `assume(type.test)`s into `assume(phi(type.test.1, type.test.2))`.

Currently we create `assume(type.test)` for all virtual calls that might be devirtualized. This is to support `-Wl,--lto-whole-program-visibility`.

To prevent this, all virtual calls that may not be in the same LTO module instead use a new `llvm.public.type.test` intrinsic in place of the `llvm.type.test`. Then when we know if `-Wl,--lto-whole-program-visibility` is passed or not, we can either replace all `llvm.public.type.test` with `llvm.type.test`, or replace all `llvm.public.type.test` with `true`. This prevents WPD from trying to pattern match away `assume(type.test)` for ...

Disable SGPRs for src0 of these opcodes.

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

1. Slightly document the "mark advanced" variable used to control the
   installed CMake package dir.

   I would document it more, but I am considering in the future adding
   pkg-config support in this manner, after which `_PACKGE_DIR` is
   probably better called `_CMAKE_PACKGE_DIR` or similar.

2. Convey the custom path to the legacy `llvm-config` binary.

Reviewed By: sebastian-ne

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

See https://cmake.org/cmake/help/v3.14/module/GNUInstallDirs.html#result-variables for `CMAKE_INSTALL_FULL_*`

Reviewed By: sebastian-ne

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

Some codepaths lead to `namespace_map == nullptr` when we get to
`ClangASTSource::FindCompleteType`. This occurred while debugging
an lldb session that had `settings set target.import-std-module true`.

In that case, with `LLDBLog::Expressions` logging enabled, we would
dereference a `nullptr` and crash.

This commit moves the logging until after we check for `nullptr`.

**Testing**

* Fixed the specific crash I was seeing while debugging an `lldb`
  session with `import-std-module` enabled.

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

Encode dst=EXEC but allow disassembler accept any dst value.

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

Otherwise we have to work pretty hard to ensure a discarded alloc/free
pair doesn't remove a return value that's still useful.

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

This helps fold away the ptest instructions, which needs the knowledge on whether
the general predicate is known to zero the inactive lanes.

This fixes some PTEST regressions introduced by D129282.

Reviewed By: paulwalker-arm

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

This fixes some PTEST regressions introduced by D129282.

Reviewed By: paulwalker-arm

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

This also adds new sve-ptest tests for FP compares that will retain
the ptest.

This also includes a few other NFC changes:
* Added type mangling to ptest.any intrinsic.
* Regenerated asm using update_llc_tests script.

Capture the computed shadow begin/end values at the point where the
shadow is first created and reuse those values on reset. Introduce new
windows-specific function "ZeroMmapFixedRegion" for zeroing out an
address space region previously returned by one of the MmapFixed*
routines; call this function (on windows) from DoResetImpl
tsan_rtl.cpp instead of MmapFixedSuperNoReserve.

See https://github.com/golang/go/issues/53539#issuecomment-1168778740
for context; intended to help with updating the syso for Go's
windows/amd64 race detector.

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

This reverts commit 05e6fce8.

I think what we need is the least Log2(EltSize) significant bits are known to be ones.

Reviewed By: RKSimon

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

Use nearest_integer instructions to improve expf performance.

Performance tests with CORE-MATH's perf tool:

Before the patch:
```
$ ./perf.sh expm1f
LIBC-location: /home/lnt/experiment/llvm/llvm-project/build/projects/libc/lib/libllvmlibc.a
GNU libc version: 2.31
GNU libc release: stable
CORE-MATH reciprocal throughput   : 10.096
System LIBC reciprocal throughput : 44.036
LIBC reciprocal throughput        : 11.575

$ ./perf.sh expm1f --latency
LIBC-location: /home/lnt/experiment/llvm/llvm-project/build/projects/libc/lib/libllvmlibc.a
GNU libc version: 2.31
GNU libc release: stable
CORE-MATH latency   : 42.239
System LIBC latency : 122.815
LIBC latency        : 50.122
```
After the patch:
```
$ ./perf.sh expm1f
LIBC-location: /home/lnt/experiment/llvm/llvm-project/build/projects/libc/lib/libllvmlibc.a
GNU libc version: 2.31
GNU libc release: stable
CORE-MATH reciprocal throughput   : 10.046
System LIBC reciprocal throughput : 43.899
LIBC reciprocal throughput        : 9.179

$ ./perf.sh expm1f --latency
LIBC-location: /home/lnt/experiment/llvm/llvm-project/build/projects/libc/lib/libllvmlibc.a
GNU libc version: 2.31
GNU libc release: stable
CORE-MATH latency   : 42.078
System LIBC latency : 120.488
LIBC latency        : 41.528
```

Reviewed By: zimmermann6

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

Use nearest_integer instructions to improve expf performance.

Performance tests with CORE-MATH's perf tool:

Before the patch:
```
$ ./perf.sh expf
LIBC-location: /home/lnt/experiment/llvm-project/build/projects/libc/lib/libllvmlibc.a
GNU libc version: 2.31
GNU libc release: stable
CORE-MATH reciprocal throughput   : 9.860
System LIBC reciprocal throughput : 7.728
LIBC reciprocal throughput        : 12.363

$ ./perf.sh expf --latency
LIBC-location: /home/lnt/experiment/llvm-project/build/projects/libc/lib/libllvmlibc.a
GNU libc version: 2.31
GNU libc release: stable
CORE-MATH latency   : 42.802
System LIBC latency : 35.941
LIBC latency        : 49.808
```

After the patch:
```
$ ./perf.sh expf
LIBC-location: /home/lnt/experiment/llvm/llvm-project/build/projects/libc/lib/libllvmlibc.a
GNU libc version: 2.31
GNU libc release: stable
CORE-MATH reciprocal throughput   : 9.441
System LIBC reciprocal throughput : 7.382
LIBC reciprocal throughput        : 8.843

$ ./perf.sh expf --latency
LIBC-location: /home/lnt/experiment/llvm/llvm-project/build/projects/libc/lib/libllvmlibc.a
GNU libc version: 2.31
GNU libc release: stable
CORE-MATH latency   : 44.192
System LIBC latency : 37.693
LIBC latency        : 44.145
```

Reviewed By: zimmermann6

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

Added tests won't modify the least Log2(EltSize) significant bits.

Reviewed By: RKSimon

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

The original implementation uses `ND->getFormalLinkage() <=
Linkage::InternalLinkage`. It is not right since the spec only says
internal linkage and it doesn't mention 'no linkage'. This matters when
we consider constructors. According to [class.ctor.general]p1,
constructors have no name so constructors have no linkage too.

Current DWARFLinker implementation does not support some debug sections
(mainly DWARF v5 sections). This patch adds diagnostic for such sections.
The warning would be displayed for critical(such that could not be removed)
sections and the source file would be skipped. Other unsupported sections
would be removed and warning message should be displayed. The zero exit
status would be returned for both cases.

Reviewed By: JDevlieghere

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

The fp128 in llvm.round and llvm.trunc is not supported in X86_64 for
now. Revert the support. To support quad precision for llvm.round and
llvm.trunc, it may should be supported using runtime.

Reviewed By: Jean Perier

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

Previously we used to desugar implications and biconditionals into
equivalent CNF/DNF as soon as possible. However, this desugaring makes
debug output (Environment::dump()) less readable than it could be.
Therefore, it makes sense to keep the sugared representation of a
boolean formula, and desugar it in the solver.

Reviewed By: sgatev, xazax.hun, wyt

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

Without this patch when using CMAKE_CXX_STANDARD=20 Microsoft compiler produces following warnings

clang\include\clang/Basic/DiagnosticIDs.h(48): warning C5054: operator '+': deprecated between enumerations of different types
clang\include\clang/Basic/DiagnosticIDs.h(49): warning C5054: operator '+': deprecated between enumerations of different types
clang\include\clang/Basic/DiagnosticIDs.h(50): warning C5054: operator '+': deprecated between enumerations of different types
clang\include\clang/Basic/DiagnosticIDs.h(51): warning C5054: operator '+': deprecated between enumerations of different types
clang\include\clang/Basic/DiagnosticIDs.h(52): warning C5054: operator '+': deprecated between enumerations of different types
clang\include\clang/Basic/DiagnosticIDs.h(53): warning C5054: operator '+': deprecated between enumerations of different types
clang\include\clang/Basic/DiagnosticIDs.h(54): warning C5054: operator '+': deprecated between enumerations of different types
clang\include\clang/Basic/DiagnosticIDs.h(55): warning C5054: operator '+': deprecated between enumerations of different types
clang\include\clang/Basic/DiagnosticIDs.h(56): warning C5054: operator '+': deprecated between enumerations of different types
clang\include\clang/Basic/DiagnosticIDs.h(57): warning C5054: operator '+': deprecated between enumerations of different types
clang\include\clang/Basic/DiagnosticIDs.h(58): warning C5054: operator '+': deprecated between enumerations of different types
clang\include\clang/Basic/DiagnosticIDs.h(59): warning C5054: operator '+': deprecated between enumerations of different types

Patch By: Godin

Reviewed By: aaron.ballman

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

This allows incomplete code such as `namespace foo {` to be modeled as a
normal sequence with the missing } represented by an empty opaque node.

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

Instead of taking a fixed set of arguments, use variadics so that
we can pass arbitrary arguments to the handler. This is the first
step towards using the handler to handle other non-assertion-related
failures, like std::unreachable and an exception being thrown in
-fno-exceptions mode, which would improve user experience by including
additional information in crashes (right now, we call abort() without
additional information).

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

Before the patch we calculated the NRVO candidate looking at the
variable's whole enclosing scope. The research in [P2025] shows that
looking at the variable's potential scope is better and covers more
cases where NRVO would be safe and desirable.

Many thanks to @Izaron for the original implementation.

Reviewed By: ChuanqiXu

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

Since clang15 is going to be branched in July 26, and C++ modules still
lack an update on ReleaseNotes. Although it is not complete yet, I think
it would be better to add one since we've done many works for C++20
Modules in clang15.

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

Further test-failure fallout from D130358. There were a handful of
uses of llvm-objdump in the CodeGen tests as well, which have taken me
longer to get to because more things had to be built.

Consider this example:

```lang=C++
struct header {
  unsigned a : 1;
  unsigned b : 1;
};
struct parse_t {
  unsigned bits0 : 1;
  unsigned bits2 : 2; // <-- header
  unsigned bits4 : 4;
};
int parse(parse_t *p) {
  unsigned copy = p->bits2;
  clang_analyzer_dump(copy);
  // expected-warning@-1 {{reg_$1<unsigned int SymRegion{reg_$0<struct Bug_55934::parse_t * p>}.bits2>}}

  header *bits = (header *)&copy;
  clang_analyzer_dump(bits->b); // <--- Was UndefinedVal previously.
  // expected-warning@-1 {{derived_$2{reg_$1<unsigned int SymRegion{reg_$0<struct Bug_55934::parse_t * p>}.bits2>,Element{copy,0 S64b,struct Bug_55934::header}.b}}}
  return bits->b; // no-warning: it's not UndefinedVal
}
```

`bits->b` should have the same content as the second bit of `p->bits2`
(assuming that the bitfields are in spelling order).

---

The `Store` has the correct bindings. The problem is with the load of `bits->b`.
It will eventually reach `RegionStoreManager::getBindingForField()` with
`Element{copy,0 S64b,struct header}.b`, which is a `FieldRegion`.
It did not find any direct bindings, so the `getBindingForFieldOrElementCommon()`
gets called. That won't find any bindings, but it sees that the variable
is on the //stack//, thus it must be an uninitialized local variable;
thus it returns `UndefinedVal`.

Instead of doing this, it should have created a //derived symbol//
representing the slice of the region corresponding to the member.
So, if the value of `copy` is `reg1`, then the value of `bits->b` should
be `derived{reg1, elem{copy,0, header}.b}`.

Actually, the `getBindingForElement()` already does exactly this for
reinterpret-casts, so I decided to hoist that and reuse the logic.

Fixes #55934

Reviewed By: martong

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