There is no real reason to differentiate.

Extracts logic from `vector::isContiguousSlice` to check whether
the trailing dim of a memref are contiguous into a dedicated hook
in BuiitinTypes.{h|cpp}.

Follow-up for https://github.com/llvm/llvm-project/pull/76848.

Properly ignore parentheses in bitwise operators.

Closes #81515

Fixes #80579.

Fix some warnings by matching types.

This reverts commit e1164d06.

This patch introduces a new `fir.cuda_kernel_launch` operation to
represents the call to CUDA kernels with the chervon notation. The
chevrons values in the parse tree can be scalar integer expr or dim3
derived type. The operation describes the grid/block values explicitly
as i32 values.

It lowers the parse-tree call to this new operation.

assertRegexpMatches is a deprecated alias for assertRegex and has been
removed in Python 3.12. This wasn't an issue previously because we used
a vendored version of the unittest module. Now that we use the built-in
version this gets updated together with the Python version used to run
the test suite.

1. add the missing condition for MC/DC in hasSubViews()
2. add style for selected line
3. remove name="Ln" attribute in the link within MC/DC views
4. remove color for \n

assertEquals is a deprecated alias for assertEqual and has been removed
in Python 3.12. This wasn't an issue previously because we used a
vendored version of the unittest module. Now that we use the built-in
version this gets updated together with the Python version used to run
the test suite.

The `_DYNAMIC` reference from `AsanDoesNotSupportStaticLinkage` ensures
that `clang++ -fsanitize=address -static` gets a linker error.
`MemprofDoesNotSupportStaticLinkage` is similar for `-fmemory-profile`.
Move the functions to sanitizer_common.h to be used by more sanitizers
on ELF platforms.

Fuchsia does not use interposition and opts out the check (its
`AsanDoesNotSupportStaticLinkage` is a no-op).

If we have a abs(sext a) we can legally perform this as a zext (abs a). 
(See the same combine in instcombine - note that the IntMinIsPoison flag
 doesn't exist in SDAG yet.)

On RVV, this is likely profitable because it may allow us to perform the arithmetic
operations involved in the abs at a narrower LMUL before widening for the user.
We could arguably avoid narrowing below DLEN, but the transform should
at worst move around the extend and create one extra vsetvli toggle if the source
could previously be handled via loads explicit w/EEW.

Reverts llvm/llvm-project#81028

The CSR address of `ssp` is 0x011.
Ref:
https://github.com/riscv/riscv-cfi/blob/main/cfi_backward.adoc#shadow-stack-pointer-ssp

First commit of the stack is a clean reland, second is  the fix.

There was a typo in the `static_assert` that meant we were asserting the
size of the pointer, not the struct.

Also changed `alignas` to be more intuitive, but that is NFC.

Ran builds in Android here: https://r.android.com/2954411

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