This reverts commit e9a48f9e.

BF16 implementation based on @joshua-arch1's
https://reviews.llvm.org/D152498
Fixed the incorrect f16 type introduced in
https://github.com/llvm/llvm-project/pull/68296



---------

Co-authored-by: Jun Sha (Joshua) <cooper.joshua@linux.alibaba.com>

This includes a couple of changes to pass behavior for OpenCL kernels.
Vulkan shaders are not impacted by the changes.

1. SPIR-V module is placed inside GPU module. This change is required for
gpu-module-to-binary to work correctly as it expects kernel function to
be inside the GPU module.
2. A dummy func.func with same kernel name as gpu.func is created. GPU
compilation pipeline defers lowering of gpu launch kernel op. Since
spirv.func is not directly tied to gpu launch kernel, a dummy func.func
is required to avoid legalization issues.
3. Use correct mapping when mapping MemRef memory space to SPIR-V
storage class for OpenCL kernels.

This is needed to mark the stack usage for the call.

With this change, I'm now able to succesfully execute spec2006int
compiled with -O0. There are still many fallbacks that need to be
addressed.

[RISCV][GISel] Remove what I think is an unnecessary insert point adjustment from RISCVCallLowering::lowerCall.

Other targets don't do this and no tests are affected by removing it.

- Do not emit variables-at-top for literals
- Do not emit an error for a missing name for literals used as call
operands.

Removes the `SPIRVAttributes.h` header from `GPU/Transforms/Passes.h`

This patch adds std::experimental::observer_ptr (n4282) and also
fixes LWG2516.

Co-Authored-By: Louis Dionne <ldionne.2@gmail.com>
Differential Revision: https://reviews.llvm.org/D63230

Source files in libc++ are added to the CMake targets only if they are
required by the configuration. We do this pretty consistently for all
configurations like no-filesystem, no-random-device, etc. but we didn't
do it for no-threads. This patch makes this consistent for no-threads,
which is helpful in reducing the amount of work required to port libc++
to some platforms without threads.

Indeed, with the previous approach, several threads-related source files
would end up including headers that might fail to compile properly on
some platforms. This issue is sidestepped entirely by making the
approach for no-threads consistent with the other configurations.

The test had 32-bit and 64-bit header sizes the wrong way around.

The print.cpp source file is only used when building on Windows. Avoid
including anything else but <__config> in the file in the case where
there's nothing to compile here at all. As a drive-by change, use
_LIBCPP_WIN32API consistently instead of _WIN32.

These tests are salvaged from https://reviews.llvm.org/D112152 which I
decided not to pursue anymore.

Public headers intended for user code should not define `__has_feature`,
because this can break preprocessor checks done later in user code, e.g.
if they test `#ifdef __has_feature` to check for real support in the
compiler.

Replace the only use in the public header with a check for it being
supported before trying to use it. Define the fallback definition in the
internal headers, so that other internal sanitizer headers can continue
to use it as preferred.

This resolves a bug reported to GCC as https://gcc.gnu.org/PR109882

When reading the bitcode input, undefined weak symbols will show up as
undefined symbols - which fails the early pass of checking for missing
symbols in symtab.reportUnresolvable(), before doing the actual LTO
compilation.

Mark such symbols as deferUndefined (added in
3785a413 /
https://reviews.llvm.org/D89004 for the -wrap option), to let them pass
through this LTO precheck. After the LTO compilation, the weak undefined
symbols will point towards an absolute null symbol as default.

Such weak undefined symbols are used for the TLS init function in the
Itanium C++ ABI, for TLS variables that potentially need to run a
constructor, when accessed across translation units.

This fixes https://github.com/llvm/llvm-project/issues/64513.

This is needed to make FP values be pased in a GPR as required by
the variadic function ABI.

Backends contain static tables of PartialMapping and ValueMapping.
Without the constexpr, the initial code from the frontend contains
a global constructor to construct each entry of the table. The clang
optimizer is able to optimize the constructors away, but gcc 8 is not
able to.

Using constexpr allows the tables to be created directly in the
frontend without requiring optimizations to be performed.

`RecordStreamer::emitInstruction` simply calls
`MCStreamer::emitInstruction` (overrided method of parent class), which
makes the override unnecessary.

Previously, if a linker argument (i.e. -Wl) is presented before any input
filenames, Gnu driver would use the InputInfo object of that argument to generate stats filename for LTO backend, causing an empty filename. This patch fixes such issue.

This completes the conversion of LocateSymbolFile into a SymbolLocator
plugin. The only remaining function is DownloadSymbolFileAsync which
doesn't really fit into the plugin model, and therefore moves into the
SymbolLocator class, while still relying on the plugins to do the
underlying work.

Opaque ptr cleanup effort (NFC).

This commit implements gpu::TargetAttrInterface for SPIR-V target
attribute. The plan is to use this to enable GPU compilation pipeline
for OpenCL kernels later.

The changes do not impact Vulkan shaders using milr-vulkan-runner.
New GPU Dialect transform pass spirv-attach-target is implemented for
attaching attribute from CLI.

gpu-module-to-binary pass now works with GPU module that has SPIR-V
module with OpenCL kernel functions inside. 

With LTO, gcc's IPA passes might drop the foo() function and then the test
will pass even on platforms where __builtin_thread_pointer is unavailable.

On PPC64, we get this as a result:
```
llvm/tools/llvm-exegesis/lib/BenchmarkRunner.cpp:361:61: error: ‘__builtin_thread_pointer’ is not supported on this targ
```

Just mark the function in the CMake configure test with the 'used' attribute to
avoid it being optimised out. The test then behaves correctly with -flto.

Tested with e.g. 'powerpc64le-linux-gnu-gcc -O2 -flto a.c'.

Reported-by: matoro
Reviewed-by: maskray
Closes: https://github.com/llvm/llvm-project/pull/70968


Signed-off-by: Sam James <sam@gentoo.org>

This is necessary in order to implement some papers like P2467R1, which
require using C++23 declarations in the dylib. It is a good habit to
keep building the dylib with a recent standard version regardless.

With this patch, we also stop strictly enforcing that the targets are
built with C++23. Concretely, C++23 will soon be required in order to
build the dylib, but not enforcing it strictly works around some issues
like the documentation bots using an old and unsupported compiler. Since
these bots do not actually build the library, not strictly enforcing the
C++ Standard makes our CMake build more resilient to these kinds of
situation. This is just a workaround though, the better way of going
about would be to update the compiler on the documentation bot but we
don't seem to have control over that.

This patch converts `CXXConstructExpr::ConstructionKind` into a scoped enum in namespace scope, making it eligible for forward declaring. This is useful in cases like annotating bit-fields with `preferred_type`.

This patch converts `PredefinedExpr::IdentKind` into a scoped enum in namespace scope, making it eligible for forward declaring. This is useful in certain contexts, such as `preferred_type` annotations on bit-fields.

I forgot that lldb/source/Plugins/CMakeLists.txt implicitly builds
all enums via LLDB_ENUM_PLUGINS / Plugins.def.in.

Now the GN build does this for the SymbolLocator plugins too.

(Also fix some minor stuff now that they actually build.)

This isn't referenced from anything yet, so no effect.
(It's not referenced yet in CMake either from what I can tell.)

This patch converts `CharacterLiteral::CharacterKind` to scoped enum in namespace scope. This enables forward declaration of this enum, which is useful in case like annotating bit-fields with `preferred_type`.

This patch converts `StringLiteral::StringKind` to a scoped enum in namespace scope. This enabled forward-declarations of this enum where necessary, e.g. for `preferred_type` annotation for bit-fields.

[ItaniumCXXABI] Add -fassume-nothrow-exception-dtor to assume that all exception objects' destructors are non-throwing

Link: https://lists.llvm.org/pipermail/cfe-dev/2021-August/068740.html ("[Exception Handling] Could we mark __cxa_end_catch as nounwind conditionally?"
Link: https://github.com/llvm/llvm-project/issues/57375

A catch handler calls `__cxa_begin_catch` and `__cxa_end_catch`. For a catch-all
clause or a catch clause matching a record type, we:

* assume that the exception object may have a throwing destructor
* emit `invoke void @__cxa_end_catch` (as the call is not marked as the `nounwind` attribute).
* emit a landing pad to destroy local variables and call `_Unwind_Resume`

```
struct A { ~A(); };
struct B { int x; };
void opaque();
void foo() {
  A a;
  try { opaque(); } catch (...) { } // the exception object has an unknown type and may throw
  try { opaque(); } catch (B b) { } // B::~B is nothrow, but we do not utilize this
}
```

Per C++ [dcl.fct.def.coroutine], a coroutine's function body implies a `catch (...)`.
Our code generation pessimizes even simple code, like:
```
UserFacing foo() {
  A a;
  opaque();
  co_return;
  // For `invoke void @__cxa_end_catch()`, the landing pad destroys the
  // promise_type and deletes the coro frame.
}
```

Throwing destructors are typically discouraged. In many environments, the
destructors of exception objects are guaranteed to never throw, making our
conservative code generation approach seem wasteful.

Furthermore, throwing destructors tend not to work well in practice:

* GCC does not emit call site records for the region containing `__cxa_end_catch`. This has been a long time, since 2000.
* If a catch-all clause catches an exception object that throws, both GCC and Clang using libstdc++ leak the allocated exception object.

To avoid code generation pessimization, add an opt-in driver option
-fassume-nothrow-exception-dtor to assume that `__cxa_end_catch` calls have the
`nounwind` attribute. This implies that thrown exception objects' destructors
will never throw.

To detect misuses, diagnose throw expressions with a potentially-throwing
destructor. Technically, it is possible that a potentially-throwing destructor
never throws when called transitively by `__cxa_end_catch`, but these cases seem
rare enough to justify a relaxed mode.

Reviewed By: ChuanqiXu

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

RISCVII::MO_HI was being passed to the offset argument instead of
the flags argument.

Adjust some other calls to not pass an explicit 0 to the offset argument
since it already has a default value of 0.

Avoids the need for explicit addDef and addReg.

When converting branches, legalize target block arguments first.

Fixes llvm#70813