This reverts commit d80fdc6f.
split-dwarf-local-impor3.ll fails because of an issue with
Dwo sections emission on Windows platform.

The GPU port of the LLVM C library needs to export a few extensions to
the interface such that users can interface with it. This patch adds the
necessary logic to define a GPU extension. Currently, this only exports
a `rpc_reset_client` function. This allows us to use the server in
D147054 to set up the RPC interface outside of `libc`.

Depends on https://reviews.llvm.org/D147054

Reviewed By: sivachandra

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

This patch begins providing a generic static library that wraps around
the raw `rpc.h` interface. As discussed in the corresponding RFC,
https://discourse.llvm.org/t/rfc-libc-exporting-the-rpc-interface-for-the-gpu-libc/71030,
we want to begin exporting RPC services to external users. In order to
do this we decided to not expose the `rpc.h` header by wrapping around
its functionality. This is done with a C-interface as we make heavy use
of callbacks and allows us to provide a predictable interface.

Reviewed By: JonChesterfield, sivachandra

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

[libc++] Merge _LIBCPP_FUNC_VIS, _LIBCPP_TYPE_VIS and _LIBCPP_EXCEPTION_ABI into _LIBCPP_EXPORTED_FROM_ABI

These macros are always defined identically, so we can simplify the code a bit by merging them.

Reviewed By: ldionne, #libc

Spies: libcxx-commits, krytarowski, smeenai

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

That is not necessary to test what we're testing, and in fact including
abort_message.cpp into that file caused some link errors if we didn't
link some of the dependencies of libc++abi directly into the test.

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

Address @v01dXYZ's comments, thanks!

This reland 5d54213e with fixes.

Testing libc++ with CMake 3.27.0-rc1 fails. It seems some of the modules
used in CMake are not included.

The error before this change was
```
CMake Error at <mono-repo>/llvm/cmake/modules/HandleLLVMOptions.cmake:821 (CHECK_C_SOURCE_COMPILES):
  Unknown CMake command "CHECK_C_SOURCE_COMPILES".
Call Stack (most recent call first):
  CMakeLists.txt:156 (include)
```

Reviewed By: thesamesam

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

libcxxrt is only used on FreeBSD and the FreeBSD CMake cache already
sets LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS to ON, as it should. This
avoids defining LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS redundantly in
a place where it doesn't belong.

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

RFC https://discourse.llvm.org/t/rfc-dwarfdebug-fix-and-improve-handling-imported-entities-types-and-static-local-in-subprogram-and-lexical-block-scopes/68544



Fixed PR51501 (tests from D112337).

1. Reuse of DISubprogram's 'retainedNodes' to track other function-local
   entities together with local variables and labels (this patch cares about
   function-local import while D144006 and D144008 use the same approach for
   local types and static variables). So, effectively this patch moves ownership
   of tracking local import from DICompileUnit's 'imports' field to DISubprogram's
   'retainedNodes' and adjusts DWARF emitter for the new layout. The old layout
   is considered unsupported (DwarfDebug would assert on such debug metadata).

   DICompileUnit's 'imports' field is supposed to track global imported
   declarations as it does before.

   This addresses various FIXMEs and simplifies the next part of the patch.

2. Postpone emission of function-local imported entities from
   `DwarfDebug::endFunctionImpl()` to `DwarfDebug::endModule()`.
   While in `DwarfDebug::endFunctionImpl()` we do not have all the
   information about a parent subprogram or a referring subprogram
   (whether a subprogram inlined or not), so we can't guarantee we emit
   an imported entity correctly and place it in a proper subprogram tree.
   So now, we just gather needed details about the import itself and its
   parent entity (either a Subprogram or a LexicalBlock) during
   processing in `DwarfDebug::endFunctionImpl()`, but all the real work is
   done in `DwarfDebug::endModule()` when we have all the required
   information to make proper emission.

Authored-by: Kristina Bessonova <kbessonova@accesssoftek.com>

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

This reduces the difference between libc++'s new.cpp and libc++abi's
stdlib_new_delete.cpp files, which are essentially copies of each other.

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

This reverts commit ed578f02.

Tests llvm/test/DebugInfo/Generic/split-dwarf-local-import*.ll fail
when x86_64 target is not registered.

These functions were previously removed due to problems running the
tests with `errno` in them. This was resolved previously by making the
internal implementation of these functions use a global `errno` so that
tests can still use `errno` functionality as long as they are run with a
single thread. This allows us to re-enable these tests as a previous
patch has also resolved the issue where the `stdlib` tests could not be
hermetic due to the dependence on system rounding functions.

Reviewed By: lntue

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

RFC https://discourse.llvm.org/t/rfc-dwarfdebug-fix-and-improve-handling-imported-entities-types-and-static-local-in-subprogram-and-lexical-block-scopes/68544



Fixed PR51501 (tests from D112337).

1. Reuse of DISubprogram's 'retainedNodes' to track other function-local
   entities together with local variables and labels (this patch cares about
   function-local import while D144006 and D144008 use the same approach for
   local types and static variables). So, effectively this patch moves ownership
   of tracking local import from DICompileUnit's 'imports' field to DISubprogram's
   'retainedNodes' and adjusts DWARF emitter for the new layout. The old layout
   is considered unsupported (DwarfDebug would assert on such debug metadata).

   DICompileUnit's 'imports' field is supposed to track global imported
   declarations as it does before.

   This addresses various FIXMEs and simplifies the next part of the patch.

2. Postpone emission of function-local imported entities from
   `DwarfDebug::endFunctionImpl()` to `DwarfDebug::endModule()`.
   While in `DwarfDebug::endFunctionImpl()` we do not have all the
   information about a parent subprogram or a referring subprogram
   (whether a subprogram inlined or not), so we can't guarantee we emit
   an imported entity correctly and place it in a proper subprogram tree.
   So now, we just gather needed details about the import itself and its
   parent entity (either a Subprogram or a LexicalBlock) during
   processing in `DwarfDebug::endFunctionImpl()`, but all the real work is
   done in `DwarfDebug::endModule()` when we have all the required
   information to make proper emission.

Authored-by: Kristina Bessonova <kbessonova@accesssoftek.com>

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

Replace the legacy legalizer versions - just use raw type sizes for now, we can add type specific handling if/when we need it

Fixes #63105

Now that we print >1 line of code snippet, we printed another line of
code for now reason, because the source range we created for the fixit
expanded to the next line, if the next token was there. Don't do that.

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

This was partially handled for log in SelectionDAG and both were
missed for GlobalISel.

This was mishandling maybe 0 * inf.

Fixes issue #63316

We should print the symbol name rather than the header name in the
message.

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

Remove undef values from the end of the vector operand in image and
buffer store instructions.
Also instead of call to computeKnownFPClass, use only findScalarElement.

Continuation of: 88421ea9 Trim zero components from buffer and image stores

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

/data/llvm-project/llvm/lib/Target/X86/X86LegalizerInfo.h:30:27: error: private field 'TM' is not used [-Werror,-Wunused-private-field]
  const X86TargetMachine &TM;
                          ^
1 error generated.

Replace the legacy legalizer versions and add initial scalar extload handling

AArch64CompressJumpTables assumes it can calculate exact block
offsets. This assumption is bogus because getInstSizeInBytes()
only returns an upper bound rather than an exact size. The
assumption is also invalid when a block alignment is bigger than
the function's alignment.

To mitigate both scenarios this patch changes the algorithm to
compute the maximum upper bound for all block offsets. This is
pessimistic but safe because all offsets are treated as unsigned.

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

This reverts commit d04452d5 since
test llvm-project/llvm/test/Bitcode/DIImportedEntity_backward.ll is broken.

RFC https://discourse.llvm.org/t/rfc-dwarfdebug-fix-and-improve-handling-imported-entities-types-and-static-local-in-subprogram-and-lexical-block-scopes/68544



Fixed PR51501 (tests from D112337).

1. Reuse of DISubprogram's 'retainedNodes' to track other function-local
   entities together with local variables and labels (this patch cares about
   function-local import while D144006 and D144008 use the same approach for
   local types and static variables). So, effectively this patch moves ownership
   of tracking local import from DICompileUnit's 'imports' field to DISubprogram's
   'retainedNodes' and adjusts DWARF emitter for the new layout. The old layout
   is considered unsupported (DwarfDebug would assert on such debug metadata).

   DICompileUnit's 'imports' field is supposed to track global imported
   declarations as it does before.

   This addresses various FIXMEs and simplifies the next part of the patch.

2. Postpone emission of function-local imported entities from
   `DwarfDebug::endFunctionImpl()` to `DwarfDebug::endModule()`.
   While in `DwarfDebug::endFunctionImpl()` we do not have all the
   information about a parent subprogram or a referring subprogram
   (whether a subprogram inlined or not), so we can't guarantee we emit
   an imported entity correctly and place it in a proper subprogram tree.
   So now, we just gather needed details about the import itself and its
   parent entity (either a Subprogram or a LexicalBlock) during
   processing in `DwarfDebug::endFunctionImpl()`, but all the real work is
   done in `DwarfDebug::endModule()` when we have all the required
   information to make proper emission.

Authored-by: Kristina Bessonova <kbessonova@accesssoftek.com>

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

InstCombine tries to swap compare operands to match sub instructions
in order to expose "CSE opportunities". However, it doesn't really
make sense to perform this transform in the middle-end, as we cannot
actually CSE the instructions there.

The backend already performs this fold in
https://github.com/llvm/llvm-project/blob/18f5446a45da5a61dbfb1b7667d27fb441ac62db/llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp#L4236
on the SDAG level, however this only works within a single basic block.

To handle cross-BB cases, we do need to handle this in the IR layer.
This patch moves the fold from InstCombine to CGP in the backend,
while keeping the same (somewhat dubious) heuristic.

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

There are static checks on the target identifiers allowed in a single
TU. Previously theses checks were only applied to HIP even though they
should be the same for OpenMP targeting AMDGPU. Simply enable these
checks for OpenMP.

Reviewed By: JonChesterfield, yaxunl

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

This patch moves the definitions of the standard IO streams to the
platform file definition. This is necessary because previously we had a
level of indirection where the stream's `FILE *` was initialized based
on the pointer to the internal `__llvm_libc` version. This cannot be
resolved ahead of time by the linker because the address will not be
known until runtime. This caused the previous implementation to emit a
global constructor to initialize the pointer to the actual `FILE *`. By
moving these definitions so that we can bind their address to the
original file type we can avoid this global constructor.

This file keeps the entrypoints, but makes them empty files only
containing an external reference. This is so they still appear as
entrypoints and get emitted as declarations in the generated headers.

Reviewed By: lntue, sivachandra

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

Replace the legacy legalizer versions

This addresses the issue found in:
https://lab.llvm.org/buildbot/#/builders/30/builds/36346

An empty structure in C has no way to be initialized, so triggering a
-Wuninitialized warning for a variable of empty structure type is not
actionable for users. This silences the false positive warning, which
matches the behavior of GCC as well.

We no longer diagnose if the structure has no members, or has only
zero-sized members (unnamed bit-fields, zero-sized bit-fields, empty
structure types).

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