This reverts commit 9cc98e33.

Issue: https://github.com/ClangBuiltLinux/linux/issues/1997

Many times I have found myself wanting to create a StringError with the
ability to interpolate a StringRef into the error string. This can be
achieved with:

StringRef Foo("...");
auto Err = createStringError(..., "Something went wrong: %s",
Foo.str().c_str());

However, this requires us to construct a temporary std::string (which
may perform a memory allocation if large enough).

I propose a new variant of `createStringError` called
`createStringErrorV` which uses `formatv` under the hood. This allows
the above example to become:

StringRef Foo("...");
auto Err = createStringErrorV(..., "Something went wrong: {0}", Foo);

Right now InProcessMemoryManager only releases a standard segment (via
sys::Memory::releaseMappedMemory) in `deallocate` when there is a
DeallocAction associated, leaving residual memory pages in the process
until termination.
Despite being a de facto memory leak, it won't cause a major issue if
users only create a single LLJIT instance per process, which is the most
common use cases. It will, however, drain virtual memory pages if we
create thousands of ephemeral LLJIT instances in the same process.

This patch fixes this issue by releasing every standard segments
regardless of the attached DeallocAction.

taking the getauxval route since elf_aux_info is available since FBSD
12.

Reverts llvm/llvm-project#82037

Breaks various buildbots:
http://45.33.8.238/linux/131051/step_7.txt
https://lab.llvm.org/buildbot/#/builders/231/builds/20751
others

Extend LegalizerHelper's API to lower integer constants to a load from
constant pool. Previously, this lowering existed only for FP constants.
Apply this change to RISCV.

processLKSections() used to be a member of RewriteInstance. Since now it
is part of the LinuxKernelRewriter, the assertion is no longer needed.

We likely accidentally removed these as part of conflict resolution.

This patch optimizes the post-increment instructions so that we can
packetize them together.
v1 = phi(v0, v3')
v2,v3  = post_load v1, 4
v2',v3'= post_load v3, 4

This can be optimized in two ways

v1 = phi(v0, v3')
v2,v3' = post_load v1, 8
v2' = load v1, 4

For the built-in local initialization function(`__cxx_global_var_init`,
`__tls_init` prefix), there could be multiple versions of the functions
in the final binary, e.g. `__cxx_global_var_init`, which is a wrapper of
global variable ctors, the compiler could assign suffixes like
`__cxx_global_var_init.N` for different ctors.
However, in the profile generation, we call `getCanonicalFnName` to
canonicalize the names which strip the suffixes. Therefore, samples from
different functions queries the same profile(only
`__cxx_global_var_init`) and the counts are merged. As the functions are
essentially different, entries of the merged profile are ambiguous. In
sample loading, for each version of this function, the IR from one
version would be attributed towards a merged entries, which is
inaccurate, especially for fuzzy profile matching, it gets multiple
callsites(from different function) but using to match one callsite,
which mislead the matching and report a lot of false positives.
Hence, we want to filter them out from the profile map during the
profile generation time. The profiles are all cold functions, it won't
have perf impact.

Update ORC information based on the new code layout and emit
corresponding ORC sections for the Linux kernel.

We rewrite ORC sections in place, which puts a limit on the size of new
section contents. Since ORC info changes for the new code layout and the
number of ORC entries can become larger, we free up space in the tables
by removing redundant ORC terminators. As a result, we effectively emit
fewer entries and have to add duplicate terminators at the end to match
the original section sizes. Ideally, we need to update ORC boundaries to
reflect the reduced size and optimize runtime lookup, but we will need
relocations for this, and the benefits will be marginal, if any.

Example:
int * const my_var = my_initializer;

Currently when transforming my_var to std::span the fixits:
- replace "int * const my_var = " with "std::span<int> const my_var {"
- add ", SIZE}" after "my_initializer" where SIZE is either inferred or
a placeholder

This patch makes that behavior less intrusive by not modifying variable
cv-qualifiers and initialization syntax.
The new behavior is:
- replace "int *" with "std::span<int>"
- add "{" before "my_initializer"
- add ", SIZE}" after "my_initializer"

This is an improvement on its own - since we don't touch the identifier,
we automatically can handle macros in them.
It also simplifies future work on initializer fixits.

This adds predefined formatting macros in C23 mode for printing unsigned
integers in binary format (e.g, __UINT_FAST64_FMTB__). These are used to
implement the PRIb (et al) macros in inttypes.h

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

In 2cea1bab, we removed the <setjmp.h> header provided by libc++. However, we did not conditionally include the underlying <setjmp.h>
header only if the C library provides one, which we otherwise do consistently (see e.g. 647ddc08).

rdar://122978778

See the two RFCs:


https://discourse.llvm.org/t/rfc-mlir-bytecode-a-stable-serialization-format/71062
https://discourse.llvm.org/t/rfc-ir-versioning/5893

Example:
int arr[10];
int * ptr = arr;

If ptr is unsafe and we transform it to std::span then the fixit we'd
currently provide transforms the code to:
std::span<int> ptr{arr, 10};

That's suboptimal as that repeats the size of the array in the code.
The idiomatic transformation should rely on the span constructor
that takes just the array argument and relies on template
parameter autodeduction to set the span size.

The transformed code should look like:
std::span<int> ptr = arr;

Note that it just should not change the initializer at all and that also
works for other forms of initialization like:
int * ptr {arr};
becoming:
std::span<int> ptr{arr};

This patch changes the initializer handling to the desired (empty)
fixit.

We were using the SDLoc corresponding to the original arithmetic
instruction, but here using the SDLoc corresponding to the original
extend if we need to introduce a new narrower extend seems cleaner.

As can be seen in the test diffs, this very minorly impacts scheduling
and register allocation by given the scheduler a hint from original
program order.

Currently we generally use `i16` to represent `bf16` in those tablegen
files. This patch is trying to use `bf16` directly.

Fix #79369.

[OpenMP][AIX] Set worker stack size to 2 x KMP_DEFAULT_STKSIZE if system stack size is too big (#81996)

This patch sets the stack size of worker threads to `2 x
KMP_DEFAULT_STKSIZE` (2 x 4MB) for AIX if the system stack size is too
big. Also defines maximum stack size for 32-bit AIX.

Our usual pattern when issuing an extension warning is to also issue a
default-off diagnostic about the keywords not being compatible with
standards before a certain point. This adds those diagnostics for C11
keywords.

This patch attempts to fix lookup in class template specialization.

The first fixed problem is that during type lookup `DeclContextGetName`
have been dropping template arguments. So when such a name was compared
against a name in `DW_AT_name`, which contains template arguments, false
mismatches have been occurring.

The second fixed problem is that LLDB's printing policy hasn't been
matching Clang's printing policy when it comes to integral non-type
template arguments. This again caused some false mismatches during type
lookup, because Clang puts e.g. `3U` in debug info for class
specializations, but LLDB has been expecting just `3`. This patch brings
printing policy in line with what Clang does.

optnone requires noinline, which is incompatible with alwaysinline.

According to DWARF spec zero entires indicate end of arange. Changed so
that BOLT does not emit zero low_pc arange.

Motivation for this and follow-on patches is to improve codegen for
libc++, where using memcpy limits optimizations, like vectorization for
code iteration over std::vector<std::complex<float>>:
https://godbolt.org/z/f3vqYos3c

Depends on https://github.com/llvm/llvm-project/pull/81289.

PR: https://github.com/llvm/llvm-project/pull/81313

This reverts commit 7b7d411d.

Fix for performance regression introduced by #80061 that slowed
down Fuchsia's MallocFree microbenchmark by 3.5 - 8%

Follow on to #81525 in the series of consolidating bits in TSFlags.

Merge SGPRSpill and VGPRSpill into single Spill bit

Modify isSGPRSpill and isVGPRSpill helper functions to differentiate
VGPR and SGPR spills:

Spill+SALU=SGPR Spill
Spill+VALU=VGPR Spill

The only exception here is SGPR spills to VGPRs which require an
explicit instruction check.

Looks like I lost this last time.

NFCish since previously we'd return false for all presplit coroutines
anyway. This clarifies things a bit.

Enough so we can enable SemaCXX/builtin-overflow.cpp.

to satisfy the __start___llvm_orderfile reference when linking with
-bexpfull and -fprofile-generate on AIX.

This is a fix forward for the Fuchsia build bot
https://lab.llvm.org/buildbot/#/builders/98/builds/33515

I've been diffing the c17 vs c23 latest publicly available drafts and think I
have most of the library related differences. I haven't yet annotated what we
actually support or not.

Link: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2310.pdf (C17)
Link: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf (C23)

This patch Implements AST node creation and appertainment enforcement
for 'parallel', as well as changes the 'not implemented' messages to be
more specific. It does not deal with clauses/clause legality, nor a few
of the other rules from the standard, but this gets us most of the way
for a framework for future construct implementation.