Reviewed By: ldionne, #libc

Spies: libcxx-commits

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

Follow up to LLVM-side change to allow conversion to hot/cold hinted
operator new, not yet standard but supported by open source tcmalloc.
The LLVM change in a35206d7 added the
necessary support to recognize these as library functions, and we
subsequently found that a clang-side change is needed to give them
builtin/nobuiltin attributes as appropriate so they have consistent
removeability.

Based on discussion with Richard Smith, converted the parameter type to
a reserved identifier (39f7b486) and
added support in this patch to recognize it in clang.

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

The unique_ptr prettyprinter calls `GetValueOfLibCXXCompressedPair`,
which looks for a `__value_` child. However, when the second value in
the compressed pair is not an empty class, there are two `__value_`
children because `__compressed_pair` derives twice from
`__compressed_pair_elem`, one for each member of the pair. And then the
lookup fails because it's ambiguous.

This patch makes the following changes:

- Rename `GetValueOfLibCXXCompressedPair` to
  `GetFirstValueOfLibCXXCompressedPair`, and add a similar function to
  get the second value. Put both functions in
  Plugin/Language/CPlusPlus/LibCxx.cpp because it seems inappropriate to
  have libcxx-specific helpers separate from all the libcxx-dependent
  code.

- Read the second value of the `__ptr_` pair and display a "deleter"
  child in the unique_ptr synthetic child provider, when available.

- Add a test case for the non-empty deleter case.

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

Similar for RISCV::parseTuneCPU and RISCV::checkTuneCPUKind.

This makes the CPUKind enum no longer part of the API. It wasn't
providing much value. It was only used to pass between the two
functions.

By removing it, we can remove a dependency on a tablegen generated
file from the RISCVTargetParser.h file. Then we can remove a
dependency from several CMakeLists.txt.

Clang was writing paths to the dependency file that don't exist when using a sysroot with symlinks, causing everything to get rebuilt every time. This is reproducible on Linux by creating a symlink to '/', using that as the sysroot, and trying to build something with ninja that includes the C++ stdlib (e.g. a typical build of LLVM).

This fixes https://github.com/ninja-build/ninja/issues/1330 and somewhat matches gcc.

gcc canonicalizes system headers in dependency files under a -f[no-]canonical-system-headers, but it makes more sense to look at -canonical-prefixes.

D37954 was a previous attempt at this.

Fixed use of %T instead of %t in test, causing bots to fail the test on the initial commit.

Reviewed By: hans

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

Reviewed By: ldionne, #libc

Spies: libcxx-commits, miyuki

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

Rather than having a separate pass to add the hint instructions,
emit them directly into the streamer during asm printing.

Reviewed By: BeMg, kito-cheng

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

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

When cuchar is compiled independently on platforms that don't have <uchar.h>, it doesn't get a declaration of mbstate_t, and so makes an empty declaration for ::mbstate_t. That conflicts with the declarations in __mbstate_t.h and cwchar since both of those headers do get mbstate_t before making ::mbstate_t.

Change `__mbstate_t.h` to just get the underlying declaration for mbstate_t and not make a declaration for ::mbstate_t. Include __mbstate_t.h in uchar.h and wchar.h when their next headers aren't available so that at least mbstate_t gets defined.

Add __std_mbstate_t.h to declare ::mbstate_t for headers that need that when cuchar or cwchar aren't available (because either _LIBCPP_HAS_NO_WIDE_CHARACTERS or _LIBCPP_CXX03_LANG).

Reviewed By: ldionne, Mordante, #libc, philnik

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

This commutes the extension (`arith.extsi`, `arith.extui`) over the
following vector ops: `vector.broadcast`, `vector.shape_cast`,
`vector.transpose`, `vector.flat_transpose`.

I focused on these as I saw them getting created by vector unroll
patterns. Maybe except `vector.flat_transpose`.

Reviewed By: antiagainst

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

Allow to commute extension ops over `vector.insertelement` and
`vector.insert_strided_slice`.

Reviewed By: antiagainst

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

Revert "[ValueTracking] Use knownbits interface for determining if `div`/`rem` are safe to speculate"

Appears to be causing out-of-tree test failures. Reverting while the
issue is investigated.

This reverts commit fbc7fcf5.

Reviewed By: aartbik

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

This reverts commit 8f0dd4ef.

Causes bot failures: https://lab.llvm.org/buildbot/#builders/139/builds/39964

This is purely so that we can expose and work through downstream codegen issues.  My intention is to see if we can get this disabled by default, but that requires fixing a bunch of downstream issues first.

Clang was writing paths to the dependency file that don't exist when using a sysroot with symlinks, causing everything to get rebuilt every time. This is reproducible on Linux by creating a symlink to '/', using that as the sysroot, and trying to build something with ninja that includes the C++ stdlib (e.g. a typical build of LLVM).

This fixes https://github.com/ninja-build/ninja/issues/1330 and somewhat matches gcc.

gcc canonicalizes system headers in dependency files under a -f[no-]canonical-system-headers, but it makes more sense to look at -canonical-prefixes.

D37954 was a previous attempt at this.

Reviewed By: hans

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

Add a new wraper type that represents either of `ExtSIOp` or `ExtUIOp`.
This is to simplify the code by using a single type, so that we do not
have to use templates or branching to handle both extension kinds.

Reviewed By: antiagainst

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

This reverts commit ade3c6a6.

This breaks the build with GCC and affects at least 2 build bots:
https://lab.llvm.org/buildbot/#/builders/217/builds/20568
https://lab.llvm.org/buildbot/#/builders/243/builds/5576

The previous code structure and comments were exceedingly confusing.  I have multiple times looked at this code and suspected a bug.  This time, I decided to take the time to reflow the code and comment out why it is correct.

The only suspect (to me) case left is that an underaligned access with a unit stride (in terms of the access type) might miss the undefined null pointer when wrapping.  This is unlikely to be an issue for C/C++ code with real page sizes, so I'm not bothering to fully convince myself whether that case is correct or not.

Remove support for compact binary sample profile format

Reviewed By: davidxl, wenlei

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

Before this patch, initialized class members would have the LifetimeKind
LK_MemInitializer, which does not allow for binding a temporary to a
reference. Binding to a temporary however is allowed in parenthesized
aggregate initialization, even if it leads to a dangling reference. To
fix this, we create a new EntityKind, EK_ParenAggInitMember, which has
LifetimeKind LK_FullExpression.

This patch does *not* attempt to diagnose dangling references as a
result of using this feature.

This patch also refactors TryOrBuildParenListInitialization(...) to
accomodate creating different InitializedEntity objects.

Fixes #61567

[0]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0960r3.html

Reviewed By: shafik

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

We have to unbox the boxchar variables in order to get to
the raw address that can be used for emboxing.

Reviewed By: jeanPerier

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

We have to keep it as a box, since taking box_addr of the optional
box may be invalid.

Reviewed By: jeanPerier

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

This patch reverts rGae739aefd7473517d3f08b5c8d08a66c7f469198 to address performance regressions reported by our [CI](https://github.com/dtcxzyw/llvm-ci/issues/137) after rG2ec1d0f427c7822540352c0c14d057e7bfe4f77b.

For example:
```
define ptr @const_gep_chain(ptr %p, i64 %a) {
    %p1 = getelementptr inbounds i8, ptr %p, i64 %a
    %p2 = getelementptr inbounds i8, ptr %p1, i64 1
    %p3 = getelementptr inbounds i8, ptr %p2, i64 2
    %p4 = getelementptr inbounds i8, ptr %p3, i64 3
    ret ptr %p4
}
```
The last three GEPs will not be folded since rG2ec1d0f427c7822540352c0c14d057e7bfe4f77b.

I think it is appropriate to remove this code because there is no compile-time regression reported in our benchmarks.

Reviewed By: nikic

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

Previously, when checking whether an in-class initializer exists when
performing parenthesized aggregate initialization, Clang checks that the
output of FieldDecl::getInClassInitializer() is non-null. This is
incorrect; if the field is part of a templated type, then
getInClassInitializer() will return nullptr if we haven't called
Sem::BuildCXXDefaultInitExpr(...) before, even if
FieldDecl::hasInClassInitializer() returns true. The end result is that
Clang incorrectly ignores the in class initializer and
value-initializes the field. The fix therefore is to instead call
FieldDecl::hasInClassInitializer(), which is what we do for braced init
lists [0].

Before this patch, Clang does correctly recognize the in-class field
initializer in certain cases. This is Sema::BuildCXXDefaultInitExpr(...)
populates the in class initializer of the corresponding FieldDecl
object. Therefore, if that method was previously called with the same
FieldDecl object, as can happen with a decltype(...) or a braced list
initialization, FieldDecl::getInClassInitializer() will return a
non-null expression, and the field becomes properly initialized.

Fixes 62266

[0]: https://github.com/llvm/llvm-project/blob/be5f35e24f4c15caf3c4aeccddc54c52560c28a0/clang/lib/Sema/SemaInit.cpp#L685

Reviewed By: shafik

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

Reviewed By: ldionne, #libc

Spies: libcxx-commits

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

The llvm-lib tool is not yet supported on z/OS.

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

Fix a bug where after
github.com/llvm/llvm-project/commit/68dd5142
refactor where we are not passing -mabi=vec-extabi to th backend.

This was briefly mentioned as a possibility in review discussion on D149369.

One slightly surprising bit to call out - these interfaces can get invoked with non-vector typed arguments. LoopVectorizer likes to call the costing interfaces with scalar types when unrolling, but not vectorizing. I found that surprising, not sure if others do.

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

The argument isn't used. VPlan-based dead recipe removal can be used
instead.

This is an attempt to troubleshoot our excessive usage of network in
Clang jobs on Buildkite.

Addresses the issue found in:
https://lab.llvm.org/buildbot/#/builders/92/builds/43478