This patch removes all of the Set.* methods from Status.

This cleanup is part of a series of patches that make it harder use the
anti-pattern of keeping a long-lives Status object around and updating
it while dropping any errors it contains on the floor.

This patch is largely NFC, the more interesting next steps this enables
is to:
1. remove Status.Clear()
2. assert that Status::operator=() never overwrites an error
3. remove Status::operator=()

Note that step (2) will bring 90% of the benefits for users, and step
(3) will dramatically clean up the error handling code in various
places. In the end my goal is to convert all APIs that are of the form

`    ResultTy DoFoo(Status& error)
`
to

`    llvm::Expected<ResultTy> DoFoo()
`
How to read this patch?

The interesting changes are in Status.h and Status.cpp, all other
changes are mostly

` perl -pi -e 's/\.SetErrorString/ = Status::FromErrorString/g' $(git
grep -l SetErrorString lldb/source)
`
plus the occasional manual cleanup.

…#102860)

This patch switches most of the uses of intptr_t to uintptr_t within
llvm-exegesis for the subprocess memory support. In the vast majority of
cases we do not want a signed component of the address, hence making
intptr_t undesirable. intptr_t is left for error handling, for example
when making syscalls and we need to see if the syscall returned -1.

We were using a `_LIBCPP_ASSERT_FOO` macro without including `<__assert>`.

rdar://134425695

…lvm#102940)

Problem:
On AIX, functions registered by atexit in a shared library are not run
when the library is dlclosed, but instead run (and fail because the
function pointer is no longer valid) during main program exit.

The profile-rt registers some functions with atexit:

 1. writeFileWithoutReturn that writes out the profile file
 2. llvm_delete_reset_function_list that does some cleanup in the gcov 
    instrumentation library (not sure)

And so right now, we get an "Illegal instruction (core dumped)" when an
instrumented shared object is dlopen'ed and dlclosed.

Solution:
  When a shared library is dlclose'd, destructors from the library are
  called. So create a destructor function that iterates over all known
  functions that profile-rt registers with atexit, and unregister the ones
  that have been registered and execute them.

Scenarios tested:
(0) gcov dlopen/dlclose                                       (AIX/gcov-dlopen-dlclose.test)
(1) multiple dlopen/dlclose of the same lib and multiple libs (instrprof-dlopen-dlclose.test)
(2) dlopen but no dlclose                                     (exists: Posix/instrprof-dlopen.test)
(3) a simple fork testcase with dlopen/dlclose                (instrprof-dlopen-dlclose.test)
(4) dlopen/dlclose by multiple threads.                       (instrprof-dlopen-dlclose.test)
(5) regular dynamic-linking of instrumented shared libs       (exists: AIX/shared-bexpall-pgo.c)
(6) a simple fork testcase produces correct profile           (instrprof-fork.c)


---------

Co-authored-by: Hubert Tong <hstong@ca.ibm.com>

Move handling of all internal calls into the designated pass. Preserve
NOPs and mark functions as non-simple on non-X86 platforms.

This patch implements sandboxir::VAArgInst mirroring llvm::VAArgInst.

…d))`; NFC

…use-count

Added folds:
    - `(add (sub X, Y), (sub Z, X))` -> `(sub Z, Y)`
    - `(sub (add X, Y), (add X, Z))` -> `(sub Y, Z)`

The fold typically is handled in the `Reassosiate` pass, but it fails
if the inner `sub`/`add` are multi-use. Less importantly, Reassosiate
doesn't propagate flags correctly.

This patch adds the fold explicitly the InstCombine

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

Closes llvm#105866

…parable with function count for each candidate (llvm#106260)

The current cost-benefit analysis between vtable comparison and function
comparison require the indirect fallback branch to be cold. This is too
conservative.

This change allows vtable-comparison as long as vtable count is
comparable with function count for each function candidate and removes
the cold indirect fallback requirement.

Tested:
1. Testing this on benchmarks uplifts the measurable performance wins.
Counting the (possibly-duplicated) remarks (because of linkonce_odr
functions, cross-module import of functions) show the number of vtable
remarks increases from ~30k-ish to 50k-ish.
2. https://gcc.godbolt.org/z/sbGK7Pacn shows vtable-comparison doesn't
happen today (using the same IR input)

…profiles for given functions (llvm#104654)

Currently in extended binary format, sample reader only read the
profiles when the function are in the current module at initialization
time, this extends the support to read the arbitrary profiles for given
input functions in later stage. It's used for
llvm#101053.

We recently added various CPU_SUBTYPE_ARM64E values, notably including
CPU_SUBTYPE_ARM64E_VERSIONED_PTRAUTH_ABI_MASK, which is 0x80000000U.
The enum is better off as a uint32_t to accomodate that.

This also hopefully helps silence GCC warnings reported on a ternary in
CPU_SUBTYPE_ARM64E_WITH_PTRAUTH_VERSION.

The subtype is already generally treated as a uint32_t elsewhere, so
while there, change the new helpers to explicitly pass/return the
subtype as uint32_t, and the individual narrower components as either
bool or unsigned.

…#106035)

In the clobbered FP/BP range, we can't use it as normal FP/BP to access
stack. So if there are stack accesses due to register spill, scheduling
or other back end optimization, we should report an error instead of
silently generate wrong code.

Also try to minimize the save/restore range of the clobbered FP/BP if
the FrameSetup doesn't change stack size.

Build on the -slp-vectorize-non-power-of-2 experimental option, and
support vectorizing reductions with 2^N-1 sized vector.

Specifically, two related changes:
1) When searching for a profitable VL, start with the 2^N-1 reduction
width.
If cost model does not select that VL, return to power of two boundaries
   when halfing the search VL.  The later is mostly for simplicity.
2) Reduce the minimum reduction width from 4 to 3 when supporting
non-power
   of two vectors.  This is required to support <3 x Ty> cases.

One thing which isn't directly related to this change, but I want to
note for clarity is that the non-power-of-two vectorization appears to
be sensative to operand order of reduction. I haven't yet fully figured
out why, but I suspect this is non-power-of-two specific.

This patch fixes:

  llvm/lib/Transforms/Instrumentation/IndirectCallPromotion.cpp:845:12:
  error: variable 'RemainingVTableCount' set but not used
  [-Werror,-Wunused-but-set-variable]

  llvm/lib/Transforms/Instrumentation/IndirectCallPromotion.cpp:306:23:
  error: private field 'PSI' is not used
  [-Werror,-Wunused-private-field]

Here are a couple of domino effects:

- Once I remove PSI, I need to update the contructor and its caller.

- Once I remove RemainingVTableCount, I don't need TotalCount, so I am
  updating the caller as well.

…NFC) (llvm#106251)

This patch forward ports the heterogeneous std::map::operator[]() from
C++26 so that we can look up the map without allocating an instance of
std::string when the key-value pair exists in the map.

The background is as follows.  I'm planning to reduce the memory
footprint of ThinLTO indexing by changing ImportMapTy, the data
structure used for an import list.  The new list will be a hash set of
tuples (SourceModule, GUID, ImportType) represented in a space
efficient manner.  That means that as we iterate over the hash set, we
encounter SourceModule as many times as GUID.  We don't want to create
a temporary instance of std::string every time we look up
ModuleToSummariesForIndex like:

auto &SummariesForIndex =
ModuleToSummariesForIndex[std::string(ILI.first)];

This patch removes the need to create the temporaries by enabling the
hetegeneous lookup with std::set<K, V, std::less<>> and forward
porting std::map::operator[]() from C++26.

llvm#105478)

Currently, `getStackAlignment` asserts if the stack alignment wasn't
specified. This makes it inconvenient to use and complicates testing.

This change also makes `exceedsNaturalStackAlignment` method redundant.

Make some minor tweaks to AMDGPU tests to ensure they still work as
intended after llvm#97762. These
tests can be radically simplified after bitcast aware fpclass deduction.

…6238)

This code has been unchanged for two years; let's simplify the code
and remove configurability which makes the code harder to follow.

…m#105832)

llvm#78086 provided the trait we want to use for this: `__libcpp_integer`.

In some `libcxx/containers/views/mdspan` tests, improper uses of `char` 
are replaced with `signed char`. 

Fixes llvm#73715

New dep needed for 2bf2468

Works towards P0619R4/llvm#99985.

- std::uncaught_exception was not previously deprecated. This patch
  deprecates it since C++17 as per N4259. std::uncaught_exceptions is
  used instead as libc++ unconditionally provides this function.

- _LIBCPP_ENABLE_CXX20_REMOVED_UNCAUGHT_EXCEPTION restores
  std::uncaught_exception.

- As a drive-by, this patch updates the C++20 status page to 
  explain that D.11 is already done, since it was done in 
  578d09c.

Certain intrinsics map to builtins that require an immediate (literal)
argument; make sure we report non-literal arguments.

This has been kicking around downstream for a while, and the recent
removal of the MMX builtins caused me to notice it again.

…irect-list-initialization (llvm#102581)

When initializing structured bindings from an array with
direct-list-initialization, array copy will be performed, which is a
special case not following list-initialization.

This PR adds support for this case.

Fixes llvm#31813.

…lvm#106269)

This helps with Constant::classof().

llvm#106293)

Reverts llvm#105442. Due to `TestSkinnyCoreFailing` and root causing of the
failure will likely take longer than EOD.

This patch decouples macOS CI testing from BuildKite, which makes the
maintenance of macOS CI easier and more accessible to all contributors.
Right now, the macOS CI is running entirely on machines owned by the
LLVM Foundation with only a small set of contributors having direct
access to them. In particular, updating these machines is currently
a very time-consuming manual process that requires taking the machines
offline, and using Github-provided instances makes that an order of
magnitude easier.

The story for performing back-deployment testing still needs to be
figured out, so for now we are retaining some jobs under BuildKite.

This patch prepares the NFC groundwork for global outlining using
CGData, which will follow
llvm#90074.

- The `MinRepeats` parameter is now explicitly passed to the
`getOutliningCandidateInfo` function, rather than relying on a default
value of 2. For local outlining, the minimum number of repetitions is
typically 2, but for the global outlining (mentioned above), we will
optimistically create a single `Candidate` for each `OutlinedFunction`
if stable hashes match a specific code sequence. This parameter is
adjusted accordingly in global outlining scenarios.
- I have also implemented `unique_ptr` for `OutlinedFunction` to ensure
safe and efficient memory management within `FunctionList`, avoiding
unnecessary implicit copies.

This depends on llvm#101461.
This is a patch for
https://discourse.llvm.org/t/rfc-enhanced-machine-outliner-part-2-thinlto-nolto/78753.

This reverts commit d1d8edf.

…lvm#102036)

We use lgamma_r for the random normal distribution support. In this
code we redeclare it, which causes issues with the LLVM C library as
this function is marked noexcept in LLVM libc. This patch ensures that
we don't redeclare that function when targeting LLVM libc.

For supported architectures, lldb will do a static scan of the assembly
instructions of a function to detect stack/frame pointer changes,
register stores and loads, so we can retrieve register values for the
caller stack frames. We trust that the function address range reflects
the actual function range, but in a stripped binary or other unusual
environment, we can end up scanning all of the text as a single
"function" which is (1) incorrect and useless, but more importantly (2)
slow.

Cap the max size we will profile to 10MB of instructions. There will
surely be functions longer than this with no unwind info, and we will
miss the final epilogue or mid-function epilogues past the first 10MB,
but I think this will be unusual, and the failure more to missing the
epilogue is that the user will need to step out an extra time or two as
the StackID is not correctly calculated mid-epilogue. I think this is a
good tradeoff of behaviors.

rdar://134391577

…lvm#106156)

LLVM often extends global names by adding suffixes to distinguish unique
identities. However, these suffixes are not always stable across
different runs and build environments. To address this issue, I
implemented `get_stable_name` to ignore such suffixes and obtain the
original name. This approach is not new, as PGO or Bolt already handle
this issue similarly. Using the stable name obtained from
`get_stable_name`, I implemented `stable_hash_name` while utilizing the
same underlying `xxh3_64bit` algorithm as before.

Fix Windows after llvm#102940

32-bit Windows uses `unsigned int` for uintptr_t and size_t.
Commit 18e06e3 changed uptr to
unsigned long, so it no longer matches the real size_t/uintptr_t and
therefore the current definition of usize result in:
`error C2821: first formal parameter to 'operator new' must be 'size_t'`

However, the real problem is that uptr is wrong to work around the fact
that we have local SIZE_T and SSIZE_T typedefs that trample on the
basetsd.h definitions of the same name and therefore need to match
exactly. Unlike size_t/ssize_t the uppercase ones always use unsigned
long (even on 32-bit).

This commit works around the build breakage by keeping the existing
definitions of uptr/sptr and just changing usize. A follow-up change
will attempt to fix this properly.

Fixes: llvm#101998

Reviewed By: mstorsjo

Pull Request: llvm#106151

… test. (llvm#106129)

Making the synthesis of a contextual profile file from a JSON descriptor more reusable, for unittest authoring purposes.

The functionality round-trips through the binary format - no reason, currently, to support other ways of loading contextual profiles.

…U objects (llvm#95292)

This patch adds the `#gpu.kernel_metadata` and `#gpu.kernel_table`
attributes. The `#gpu.kernel_metadata` attribute allows storing metadata
related to a compiled kernel, for example, the number of scalar
registers used by the kernel. The attribute only has 2 required
parameters, the name and function type. It also has 2 optional
parameters, the arguments attributes and generic dictionary for storing
all other metadata.

The `#gpu.kernel_table` stores a table of `#gpu.kernel_metadata`,
mapping the name of the kernel to the metadata.

Finally, the function `ROCDL::getAMDHSAKernelsELFMetadata` was added to
collect ELF metadata from a binary, and to test the class methods in
both attributes.

Example:
```mlir
gpu.binary @binary [#gpu.object<#rocdl.target<chip = "gfx900">, kernels = #gpu.kernel_table<[
    #gpu.kernel_metadata<"kernel0", (i32) -> (), metadata = {sgpr_count = 255}>,
    #gpu.kernel_metadata<"kernel1", (i32, f32) -> (), arg_attrs = [{llvm.read_only}, {}]>
  ]> , bin = "BLOB">]

```
The motivation behind these attributes is to provide useful information
for things like tunning.

---------

Co-authored-by: Mehdi Amini <joker.eph@gmail.com>

An overload of `llvm::promoteCallWithIfThenElse` that updates the contextual profile.

High-level, this is very simple: after creating the `if... then (direct call) else (indirect call)` structure, we instrument the new callsites and BBs (the instrumentation will help with tracking for other IPO transformations, and, ultimately, to match counter values before flattening to `MD_prof`).

In more detail:

- move the callsite instrumentation of the indirect call to the `else` BB, before the indirect call
- create a new callsite instrumentation for the direct call
- create instrumentation for both the `then` and `else` BBs - we could instrument just one (MST-style) but we're not running the binary with this instrumentation, and at most this would save some space (less counters tracked). For simplicity instrumenting both at this point
- update each context belonging to the caller by updating the counters, and moving the indirect callee to the new, direct callsite ID

Issue llvm#89287

…ng (llvm#104642)

No Functional Changes

* Fix comments in several places
* Instead of using BB-getName() (in dump methods) use
getBasicBlockLabel. This fixes the poor output of the dumped info that
resulted in missing BB labels.
* Use RPO when dumping SuspendCrossingInfo. Without this the dump order
is determined by the ptr addresses and so is not consistent from run to
run making IR diffs difficult to read.
* Inference -> Interference
* Pull the logic that determines insertion location out of insertSpills
and into getSpillInsertionPt, to differentiate between these two
operations.
* Use Shape getters for CoroId instead of getting it manually.

---------

Co-authored-by: tnowicki <tnowicki.nowicki@amd.com>

Fix docs modified by llvm#94910 by adding information about the `module`
argument in `gpu::TargetAttrInterface::createObject`.

---------

Co-authored-by: Mehdi Amini <joker.eph@gmail.com>

…alASTSourceWrapper

This is an oversight from llvm#104817 where the intention
was to hoist the ExternalASTSourceWrapper construction out of the
conditional so it can be set on both the `SemaSourceWithPriorities` and
be added as an external source to Sema. But the inner
`ExternalASTSourceWrapper` allocation wasn't actually removed.

This currently all works fine because all these AST sources are
refcounted and point to the same underlying AST sources. But this
patch cleans this up regardless.

Tail duplication will generate the redundant move before return. It is
because the MachineCopyPropogation can't recognize COPY after post-RA
pseudoExpand.

This patch make MachineCopyPropogation recognize `%0 = ADDI %1, 0` as
COPY

Add missing dependency that sometimes makes a build fails with ninja.

llvm#106120 Simplify the data transfer when possible by using the reference
and a shape. This bypass the declare op. In order to keep the declare op
around, use the second results of the declare op which achieve the same.

Fix strsep interceptor.
For strsep description see
https://www.man7.org/linux/man-pages/man3/strsep.3.html

For 016e1eb

For 73c3b73

`JITDylibSearchOrderResolver` local variable can be destroyed before
completion of all callbacks. Capture it together with `Deps` in
`OnEmitted` callback.

Original error:

```
==2035==ERROR: AddressSanitizer: stack-use-after-return on address 0x7bebfa155b70 at pc 0x7ff2a9a88b4a bp 0x7bec08d51980 sp 0x7bec08d51978
READ of size 8 at 0x7bebfa155b70 thread T87 (tf_xla-cpu-llvm)
    #0 0x7ff2a9a88b49 in operator() llvm/lib/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.cpp:55:58
    #1 0x7ff2a9a88b49 in __invoke<(lambda at llvm/lib/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.cpp:55:9) &, const llvm::DenseMap<llvm::orc::JITDylib *, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr, void> >, llvm::DenseMapInfo<llvm::orc::JITDylib *, void>, llvm::detail::DenseMapPair<llvm::orc::JITDylib *, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr, void> > > > &> libcxx/include/__type_traits/invoke.h:149:25
    #2 0x7ff2a9a88b49 in __call<(lambda at llvm/lib/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.cpp:55:9) &, const llvm::DenseMap<llvm::orc::JITDylib *, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr, void> >, llvm::DenseMapInfo<llvm::orc::JITDylib *, void>, llvm::detail::DenseMapPair<llvm::orc::JITDylib *, llvm::DenseSet<llvm::orc::SymbolStringPtr, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr, void> > > > &> libcxx/include/__type_traits/invoke.h:224:5
    #3 0x7ff2a9a88b49 in operator() libcxx/include/__functional/function.h:210:12
    #4 0x7ff2a9a88b49 in void std::__u::__function::__policy_invoker<void (llvm::DenseMap<llvm::orc::JITDylib*, llvm::DenseSet<llvm::orc::SymbolStringPtr,
```

Fix the message part of bugfix commit `2ef3dcf`.

…ang subproject" (llvm#106267)

Reverts llvm#102647

I am reverting this change because the `readfile` doesn't actually
perform any useful operation, and yet, for some reason, the test still
passed. This indicates that the modification was unnecessary and could
lead to confusion or unexpected behavior in the future.

…106013)

Fixes llvm#105898.

…lvm#106175)

It doesn't make sense to remove the space between new/delete and a
C-style cast when SpaceBeforeParensOptions.AfterPlacementOperator is set
to false.

Fixes llvm#105628.

I am interested in helping contribute macOS binaries since we're
generally sporadic with uploading these.

Fixes llvm#106016

…ve support.

This allows us to rewrite part of StaticLibraryDefinitionGenerator in terms of
loadLinkableFile.

It's also useful for clients who may not know (either from file extensions or
context) whether a given path will be an object file, an archive, or a
universal binary.

rdar://134638070

…Op pass (llvm#106229)

This is currently not controllable by the user and always set to
`DIEmissionKind::LineTablesOnly`.
The added option allows to set it to the other values accepted by LLVM
(`None`, `Full`, and `DebugDirectivesOnly`).

---------

Co-authored-by: jingzec <jingzec@nvidia.com>

These methods already returned a uniquely owned object, this just makes
them self-documenting.

…)"

This reverts commit 3c5ab5a while I investigate
bot failures (e.g. https://lab.llvm.org/buildbot/#/builders/163/builds/4286).

Fix the ERROR: UndefinedBehaviorSanitizer, reproduced by
  BUILDBOT_REVISION=43ffe2eed llvm-zorg/zorg/buildbot/builders/sanitizers/buildbot_bootstrap_ubsan.sh
It might be also related to llvm#76202

The list of load.x is refer to canFoldIntoAddrMode on D152828.
Also support LDRSroX missed in canFoldIntoAddrMode

…t globals 3/3 (llvm#105648)

Fix some false negatives of StackAddrEscapeChecker:
- Output parameters
  ```
  void top(int **out) {
    int local = 42;
    *out = &local; // Noncompliant
  }
  ```
- Indirect global pointers
  ```
  int **global;

  void top() {
    int local = 42;
    *global = &local; // Noncompliant
  }
  ```

Note that now StackAddrEscapeChecker produces a diagnostic if a function
with an output parameter is analyzed as top-level or as a callee. I took
special care to make sure the reports point to the same primary location
and, in many cases, feature the same primary message. That is the
motivation to modify Core/BugReporter.cpp and Core/ExplodedGraph.cpp

To avoid false positive reports when a global indirect pointer is
assigned a local address, invalidated, and then reset, I rely on the
fact that the invalidation symbol will be a DerivedSymbol of a
ConjuredSymbol that refers to the same memory region.

The checker still has a false negative for non-trivial escaping via a
returned value. It requires a more sophisticated traversal akin to
scanReachableSymbols, which out of the scope of this change.

CPP-4734

---------

This is the last of the 3 stacked PRs, it must not be merged before
llvm#105652 and
llvm#105653

…lvm#106338)

…vm#106233)

Currently, `llvm-cxxfilt` will strip the leading underscore of its input
on macOS. Historically MachO symbols were prefixed with an extra
underscore and this is why this default exists. However, nowadays, the
`ItaniumDemangler` supports all of the following mangling prefixes:
`_Z`, `__Z`, `___Z`, `____Z`. So really `llvm-cxxfilt` can simply
forward the mangled name to the demangler and let the library decide
whether it's a valid encoding.

Compiling C++ on macOS nowadays will generate symbols with `_Z` and
`___Z` prefixes. So users trying to demangle these symbols will have to
know that they need to add the `-n` prefix. This routinely catches
people off-guard.

This patch removes the `-n` default for macOS and allows calling into
the `ItaniumDemangler` with all the `_Z` prefixes that the demangler
supports (1-4 underscores).

rdar://132714940

Alignment and start with an upper-case letter.

S.substr(N) is simpler than S.slice(N, StringRef::npos). Also, substr
is probably better recognizable than slice thanks to
std::string_view::substr.

…pes for `std::isnormal` (llvm#104773)

## Why
Currently, the following does not work when compiled with clang:

```c++
#include <cmath>

struct ConvertibleToFloat {
    operator float();
};

bool test(ConvertibleToFloat x) {
    return std::isnormal(x);
}
```
See https://godbolt.org/z/5bos8v67T for differences with respect to
msvc, gcc or icx. It fails for `float`, `double` and `long double` (all
cv-unqualified floating-point types).

## What
Test and provide overloads as expected by the ISO C++ standard. The
classification/comparison function `isnormal` is defined since C++11
until C++23 as
```c++
bool isnormal( float num );
bool isnormal( double num );
bool isnormal( long double num );
```
and since C++23 as
```c++
constexpr bool isnormal( /* floating-point-type */ num );
```
for which "the library provides overloads for all cv-unqualified
floating-point types as the type of the parameter num". See §28.7.1/1 in
the [ISO C++
standard](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/n4950.pdf)
or check
[cppreference](https://en.cppreference.com/w/cpp/numeric/math/isnormal).

…tor (llvm#103716)

With this patch, clang now automatically adds
``[[clang::lifetimebound]]`` to the parameters of `std::span,
std::string_view` constructors, this enables Clang to capture more cases
where the returned reference outlives the object.


Fixes llvm#100567

…n optimizations

This patch tries to salvage the debug information for the coroutine
frames within optimizations by creating the help alloca varaibles with
optimizations too. We didn't do this when I implement it initially. I
roughtly remember the reason was, we feel the additional help alloca
variable may pessimize the performance, which is almost the most
important thing under optimizations. But now, it looks like the new
inserted help alloca variables can be optimized out by the following
optimizations. So it looks like the time to make it available within
optimizations.

And also, it looks like the following optimizations will convert the
generated dbg.declare instrinsic into dbg.value intrinsic within
optimizations.

In LLVM's test, there is a slightly regression
that a dbg.declare for the promise object failed to be remained after
this change. But it looks like we won't have a chance to see dbg.declare
for the promise object when we split the coroutine as that dbg.declare
will be converted into a dbg.value in early stage.

So everything looks fine.

…#106240)

If a mutex interface is split in inheritance chain, e.g. struct mutex
has `unlock` and inherits `lock` from __mutex_base then calls m.lock()
and m.unlock() have different "this" targets: m and the __mutex_base of
m, which used to confuse the `ActiveCritSections` list.

Taking base region canonicalizes the region used to identify a critical
section and enables search in ActiveCritSections list regardless of
which class the callee is the member of.

This likely fixes llvm#104241

CPP-5541

…lvm#105521)

This is similar to how the C++ API supports passing `nullptr` to
`setPersonalityFn` or `setInitializer`.

…p-reduction.ll. (llvm#102907)

Use ConstantFoldLoadFromConst() instead of a partial re-implementation.
This makes the code slightly more generic by not depending on the
exact structure of the constant.

[CWG2917](https://cplusplus.github.io/CWG/issues/2917.html) got a new
proposed resolution that is different from the one the test has been
written against.

[CWG2922](https://cplusplus.github.io/CWG/issues/2922.html) apparently
the initial "possible resolution" was approved without changes.

Reverts llvm#105496

This patch breaks:
https://lab.llvm.org/buildbot/#/builders/25/builds/1952
https://lab.llvm.org/buildbot/#/builders/52/builds/1775

Somehow output is different with sanitizers.
Maybe non-determinism in the code?

We're generally not able to simplify signed pointer comparisons
(because we don't have no-wrap flags that would permit it), so
we shouldn't pretend that we can in the cost model.

The unsigned comparison case is also not modelled correctly,
as explained in the added comment. As this is a cost model
inaccuracy at worst, I'm leaving it alone for now.

This API is faster than getMinusSCEV() and a SCEVConstant cast.

Just need to add powi test with llvm#105775

…sfinite}` (llvm#106224)

## Why
Since llvm#98841 and
llvm#98952, the constrained
overloads are unused and not needed anymore as we added explicit
overloads for all floating point types. I forgot to remove them in the
mentioned PRs.

## What
Remove them.

…lvm#105665)

In the clang user manual the build options `CLANG_CONFIG_FILE_USER_DIR`
and `CLANG_CONFIG_FILE_SYSTEM_DIR` are documented, but the run time
overrides `--config-user-dir` and `--config-system-dir` are not.

I have updated the manual to add these run time arguments.

WideInc/WideIncExpr can be null. Previously this worked out
because the comparison with WideIncExpr would fail. Now we have
accesses to WideInc prior to that. Avoid the issue with an
explicit check.

Fixes llvm#106239.

from PEP8
(https://peps.python.org/pep-0008/#programming-recommendations):

> Comparisons to singletons like None should always be done with is or
is not, never the equality operators.

Co-authored-by: Eisuke Kawashima <e-kwsm@users.noreply.github.com>