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

This change will switch SizeClassAllocator32 to SizeClassAllocator64 on ARM. This might potentially affect ARM platforms with 39-bit address space. This addresses [[ https://github.com/google/sanitizers/issues/703  | issues/703  ]], but unlike [[ https://reviews.llvm.org/D60243 | D60243 ]] it defaults to 64 bit allocator.

Reviewed By: vitalybuka, MaskRay

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

These were accidentally set to generating in
243da90e

Reviewed By: #libc, philnik

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

Remove the eliminateBlockingAwaitOps option in AsyncToAsyncRuntime pass

Today the AsyncToAsyncRuntime pass does two things: one is converting normal funcs with async ops to coroutine cfg; the other is lowering high level async operations to async.coro and async.runtime operations. This patch removes the converting step from AsyncToAsyncRuntime pass.

In the next step we will create a new asyncfication pass for converting normal funcs to the newly added async.func operation.

Reviewed By: ezhulenev

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

This change modifies the implementation of the format() function
so that vendor forks committed to building with compilers that
support __attribute__((format)) on non-variadic functions can
check the format() function with it.

rdar://84571523

RVVBitsPerBlock is 64. If VLen==32, VLen/RVVBitsPerBlock is 0.

Reviewed By: reames

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

Fix setting affinity type and topology method when affinity is disabled
and fix places that were not taking into account that affinity can be
explicitly disabled by putting proper KMP_AFFINITY_CAPABLE() check.

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

Fixes #58188.

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

This was causing failures when optimizing codes with complex numbers.
Revert until a fix can be implemented.

This reverts commit 7fdf3564.

The linker wrapper does its own library searching for static archives
that can contain device code. The device linking phases happen before
the host linking phases so that we can generate the necessary
registration code and link it in with the rest of the code. Previously,
If a library containing needed device code was not found the execution
would continue silently until it failed with undefined symbols. This
patch allows the linker wrapper to perform its own check beforehand to
catch these errors.

Reviewed By: jdoerfert

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

If a function is renamed with `__asm__`, the name provided is the
exact symbol name, without any extra implicit symbol prefixes.
If the target does use symbol prefixes, the IR level symbol gets
an `\01` prefix to indicate that it's a literal symbol name to be
taken as is.

When a builtin function is specialized by providing an inline
version of it, that inline function is named `<funcname>.inline`.

When the base function has been renamed due to `__asm__`, the inline
function ends up named `<asmname>.inline`. Up to this point,
things did work as expected before.

However, for targets with symbol prefixes, one codepath that produced
the combined name `<asmname>.inline` used the mangled `asmname` with
`\01` prefix, while others didn't. This patch fixes this.

This fixes the combination of asm renamed builtin function, with
inline override of the function, on any target with symbol
prefixes (such as i386 windows and any Darwin target).

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

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

Accompanying https://reviews.llvm.org/D125728, this updates LLVM
Codegen's "generic" CPU to enable the same new features.

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

Fix path that generates MutableBox for
pointer component.

Reviewed By: PeteSteinfeld

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

This is required for D126305 code to propagate fastmath attributes
for Arith operations that are converted to LLVM IR intrinsics
operations.

LLVM IR intrinsic operations are using custom assembly format now
to avoid printing {fastmathFlags = #llvm.fastmath<none>}, which
is too verbose.

Reviewed By: rriddle

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

This doesn't affect our ABI because `std::string::substr()` isn't in the dylib and the mangling of `substr() const` and `substr() const&` are different.

Reviewed By: ldionne, Mordante, var-const, avogelsgesang, #libc

Spies: arphaman, huixie90, libcxx-commits

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

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

This patch moves the implementation of the loadOffloadInfoMetadata to the OMPIRbuilder.

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

This was originally part of https://reviews.llvm.org/D136925, but we decided to move it to a separate patch.
In case it turns out to be controversial, it can be reverted more easily.

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

Add Async Function to the Async Dialect

Today `async.execute` operation semantics requires attached region to be executed in a thread managed by the runtime, and always returns an `!async.token` result. We need to model async functions that are not necessarily executed in a runtime-managed threads, but eventually lowered to llvm coroutines.

Example:

```
async.func @foo(%arg0: !async.value<f32>) -> !async.token {
  %0 = async.await %arg0: !async.value<f32>
  "do_something_with_f32"(%0)
  return
}
```

If `arg0` is available this function will be executed in the caller thread. If it's not available it will be suspended and resumed later later on a thread managed by the async runtime. Currently this is not representable with `async.execute` operations.

The longer term goal is to make async dialect more like https://github.com/lewissbaker/cppcoro to be able to represent structured host concurrency in MLIR.

(1) Add async.func, async.call, and async.return operations in Async Dialect

Reviewed By: ezhulenev, rriddle

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

This should address the issue found in:
https://lab.llvm.org/buildbot/#/builders/30/builds/27824

Add `COMPILER_RT_LIBDISPATCH_CFLAGS` to `TSAN_RTL_CFLAGS` before it gets
duplicated to `TSAN_RTL_DYNAMIC_CFLAGS` so both versions have the
necessary flags.

Reviewed By: wrotki, rsundahl

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

This fixes crashes when vector compares can be simplified to true/false.

Reviewed By: dcaballe

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

Extracts part of populateInstruction into a separate
addOneOperandFields function.

This reverts commit 12d8e7c6.

The Windows MLIR buildbot started failing with:

C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\um\winbase.h(9531): error C2220: the following warning is treated as an error
C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\um\winbase.h(9531): warning C5105: macro expansion producing 'defined' has undefined behavior
C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\um\winbase.h(9531): note: to simplify migration, consider the temporary use of /Wv:18 flag with the version of the compiler with which you used to build without warnings

The MIR test somewhat depends on target support.

This was taking the MachineFunction, but only inspecting the
underlying IR.

The legacy PM allowed you to set a custom inliner threshold via
  builder.Inliner = llvm::createFunctionInliningPass(inline_threshold);

This allows the same thing to be done with the new PM optimization pipelines.

Reviewed By: asbirlea

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

Reviewed By: awarzynski, asbirlea

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

See [1] for background.

Some people have complained that `opt -passes=instcombine` is a lot more typing than `opt -instcombine`.
As a compromise that nobody has objected to in [1], allow `opt -p instcombine`.

[1] https://discourse.llvm.org/t/rfc-legacy-opt-pass-syntax-with-new-pass-manager/65863

Reviewed By: bjope, asbirlea

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

Context: I plan on using this change primarily downstream in the apple
fork of llvm to track swift module loading time.

Reviewed By: clayborg, tschuett

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

Remove the `--src-root` option from the deprecated llvm-config tool.
None of the llvm-project projects use this option anymore. The value
was only meaningful for in-tree use and usually became no longer correct
once LLVM was installed -- either because it was built in a temporary
directory, or installed from a binary package and built on a different
system entirely.  Therefore, third-party tools could not have been
relying on it anyway.

The LLVM_SRC_ROOT #define is left intact, as it is used to compute
includedir when llvm-config is used in-source.

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

This patch should land before D137136 to make sure that the leak sanitizer allocator works correctly. This patch is NFC without D137136.

Reviewed By: vitalybuka

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

For some auto-generated sources, we have a huge number of critical
edges (like from switch statements). We have seen instance of 183777
critical edges in one function.

After we split the critical edges in PGO instrumentation/profile-use
pass, the CFG is so large that we have compiler time issues in
downstream passes (like in machine CSE and block placement). Here I
add a threshold to skip PGO if the number of critical edges are too
large.

The threshold is large enough so that it will not affect the majority
of PGO compilation.

Also sync the logic for skipping instrumentation and profile-use. I
think this is the correct thing to do.

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