This reverts commit b756096b.
See regression https://github.com/llvm/llvm-project/issues/58774

This change-set defines the LoweringOptions the same way
other options are defined in Flang.

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

This patch fixes codegen for `[su]itofp` instructions.

In LoongArch, a legal int-to-float conversion is done in two steps:

1. Move the data from `GPR` to `FPR`. (FRLen >= GRLen)
2. Conversion in `FPR`. (the data in `FPR` is treated as a signed value)

Based on the above features, when the type's BitWidth meets the
requirements, all `SINT_TO_FP` are legal, all `UINT_TO_FP` are expand
and lowered to libcall when appropriate.
The only special case is, LoongArch64 with `+f,-d` features. At this
point, custom processing is required for `[SU]INT_TO_FP`. Of course, we
can also ignore it and use libcall directly.

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

CMPSXADD will modify memory, so we can't use `IntrArgMemOnly` here.
Found it during review D137250.

Fix a brown paper bag error made by me in D129418.  I didn't set
ASAN_INTERCEPT_VFORK correctly for loongarch64, but created an all-zero
object for __interception::real_vfork.  This caused anything calling
vfork() to die instantly.

Fix this issue by setting ASAN_INTERCEPT_VFORK and remove the bad
all-zero definition.  Other ports have an all-zero common definition but
we don't need it at least for now.

And, enable ASAN vfork test for loongarch64 to prevent regression in the
future.

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

Instrumentation passes now use the proper shadow offset. There will be many
asan test failures without this patch. For example:

```
$ ./lib/asan/tests/LOONGARCH64LinuxConfig/Asan-loongarch64-calls-Test
AddressSanitizer:DEADLYSIGNAL
=================================================================
==651209==ERROR: AddressSanitizer: SEGV on unknown address 0x1ffffe2dfa9b (pc 0x5555585e151c bp 0x7ffffb9ec070 sp 0x7ffffb9ebfd0 T0)
==651209==The signal is caused by a UNKNOWN memory access.
```

Before the patch:

```
$ make check-asan
Testing Time: 36.13s
  Unsupported      : 205
  Passed           :  83
  Expectedly Failed:   1
  Failed           : 239
```

After the patch:
```
$ make check-asan
Testing Time: 58.98s
  Unsupported      : 205
  Passed           : 421
  Expectedly Failed:   1
  Failed           :  89
```

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

This enables odr indicators on all platforms and private aliases on non-Windows.
Note that GCC also uses private aliases: this fixes bogus
`The following global variable is not properly aligned.` errors for interposed global variables

Fix https://github.com/google/sanitizers/issues/398
Fix https://github.com/google/sanitizers/issues/1017
Fix https://github.com/llvm/llvm-project/issues/36893 (we can restore D46665)

Global variables of non-hasExactDefinition() linkages (i.e.
linkonce/linkonce_odr/weak/weak_odr/common/external_weak) are not instrumented.
If an instrumented variable gets interposed to an uninstrumented variable due to
symbol interposition (e.g. in issue 36893, _ZTS1A in foo.so is resolved to _ZTS1A in
the executable), there may be a bogus error.

With private aliases, the register code will not resolve to a definition in
another module, and thus prevent the issue.

Cons: minor size increase. This is mainly due to extra `__odr_asan_gen_*` symbols.
(ELF) In addition, in relocatable files private aliases replace some relocations
referencing global symbols with .L symbols and may introduce some STT_SECTION symbols.

For lld, with -g0, the size increase is 0.07~0.09% for many configurations I
have tested: -O0, -O1, -O2, -O3, -O2 -ffunction-sections -fdata-sections
-Wl,--gc-sections. With -g1 or above, the size increase ratio will be even smaller.

This patch obsoletes D92078.

Don't migrate Windows for now: the static data member of a specialization
`std::num_put<char>::id` is a weak symbol, as well as its ODR indicator.
Unfortunately, link.exe (and lld without -lldmingw) generally doesn't support
duplicate weak definitions (weak symbols in different TUs likely pick different
defined external symbols and conflict).

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

This document aims to give insights at the representation of procdure
pointers in FIR.

Reviewed By: PeteSteinfeld, jeanPerier, kiranchandramohan

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

It's not necessary to redo the source file preprocessing for reproducing linker
crashes because we must have successfully created the object file by this point.
Skip this step, and also don't report the preprocessed source file or create
the clang invocation shell script. The latter is no longer sensible without the
preprocessed source, or helpful given the linker reproducer will have it's own
shell script.

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

Materializing scalable vectors with boolean values is not implemented
yet. Skip those cases for now and leave a TODO.

Per discussions in D128745, remove ClangABICompat checks for implementations
of DR692/DR1395/DR1432. This is a potentially breaking changes, so the release
note is updated accordingly.

Reviewed By: aaron.ballman

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

Fixes null dereference in emitFunctionBodyStart for 64-bit

The empty set will be default constructed if this wasn't
in the map already.

The call_intrinsic op allows us to call LLVM intrinsics from the LLVMDialect without implementing a new op every time.

Reviewed By: lattner, rriddle

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

A bug in the file read logic has also been fixed along the way. Parts
of the ungetc tests will fail without that bug fixed.

Reviewed By: michaelrj

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

The instruction icmp ule <4 x i32> %0, zeroinitializer will usually be
simplified to icmp eq <4 x i32> %0, zeroinitializer. It is not
guaranteed though, and the code for lowering vector compares could pick
the wrong form of the instruction if this happened. I've tried to make
the code more explicit about the supported conditions.

This fixes NEON being unable to select VCMPZ with HS conditions, and
fixes some incorrect MVE patterns.

Fixes #58514.

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

This target (as well as 32-bit ARM Android) have sizeof(long double)
equal to sizeof(double).

Reviewed By: ldionne, #libc

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

Mark tests XFAIL that use APIs that are unsupported on old versions of
Android:
 - aligned_alloc isn't available until API 28.
 - timespec_get isn't available until API 29.

Reviewed By: ldionne, #libc

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

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