Factor out utility to simplify D147964 as sugested.

We filed some CD ballot comments which WG14 considered during the
ballot comment resolution meetings in Jan and Feb 2023, and this
updates our implementation based on the decisions reached. Those
decisions were (paraphrased for brevity):

US 9-034 (REJECTED)
  allow (void *)nullptr to be a null pointer constant
US 10-035 (ACCEPTED)
  accept the following code, as in C++:
  void func(nullptr_t); func(0);
US 22-058 (REJECTED)
  accept the following code, as in C++:
  nullptr_t val; (void)(1 ? val : 0); (void)(1 ? nullptr : 0);
US 23-062 (REJECTED)
  reject the following code, as in C++:
  nullptr_t val; bool b1 = val; bool b2 = nullptr;
US 24-061 (ACCEPTED)
  accept the following code, as in C++:
  nullptr_t val; val = 0;
US 21-068 (ACCEPTED)
  accept the following code, as in C++:
  (nullptr_t)nullptr;
GB-071 (ACCEPTED)
  accept the following code, as in C++:
  nullptr_t val; (void)(val == nullptr);

This patch updates the implementation as appropriate, but is primarily
focused around US 10-035, US 24-061, and US 23-062 in terms of
functional changes.

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

Keeping this false could end up with extra iterations on a lot of loops
that aren't real ones (e.g. they could be a do-while-false for macros),
and makes the analyses very slow.

This patch changes the default for
CFG::BuildOptions.PruneTriviallyFalseEdges to true to avoid it.

Reviewed By: ymandel, xazax.hun, gribozavr2

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

Argument promotion mostly works on functions with more than one caller (otherwise the function would be inlined or is dead), so there's a good chance that performing this increases code size since we introduce loads at every call site. If any caller is marked minsize, bail.

We could compare the number of loads/stores removed from the function with the number of loads introduced in callers, but that's TODO.

Reviewed By: nikic

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

Internal testing showed that the change made in commit 62fcfc5a needed
more test coverage. Specifically, the imported function shouldn't be
externally visibile and the whole test needed to be run in regular LTO
mode.

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

Decimal long doubles are not commonly used, and aren't currently
supported by the algorithm used for decimal float conversions. To avoid
giving incorrect answers, this patch adds a temporary exception to print
long doubles in hexadecimal even when decimal is requested.

Reviewed By: sivachandra

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

This patch adds the function "socket" from the header "sys/socket". It's
a simple syscall wrapper, and I plan on adding the related functions in
a followup patch.

Reviewed By: sivachandra

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

These rely on the `ValueBounds` interace and its utility function to
compute constant bounds. This allows us to optimize `linalg.index`
values cast to integer types.

Reviewed By: antiagainst

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

they are completed.

The qHostInfo packet in the gdb-remote communication protocol specifies
that distribution_id can be set, so lldb handles that. But we store that
in the ArchSpec representing the "Host" platform (whatever platform the
debug server is running on). This field is otherwise unused in ArchSpec,
so it would be a lot easier if we stored that information at the
gdb-remote communication layer.

Sidenote: The distribution_id field is currently unused but I did not
want to remove it in case some folks found it useful (e.g. in downstream
forks).

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

No call sites use these parameters, so drop them.
Equivalent to D148940.

Reviewed By: MaskRay

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

The checker alpha.security.ArrayBoundV2 created bug reports in
situations when the (tainted) result of fgetc() or getchar() was passed
to one of the isXXXXX() macros from ctype.h.

This is a common input handling pattern (within the limited toolbox of
the C language) and several open source projects contained code where it
led to false positive reports; so this commit suppresses ArrayBoundV2
reports generated within the isXXXXX() macros.

Note that here even true positive reports would be difficult to
understand, as they'd refer to the implementation details of these
macros.

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

We got rid of the rounding mode here so that the hermetic tests wouldn't
depend on the system fenv.h. But this seemed to cause some bots to
break. Getting rid of this change for now, it should be fine for the CPU
builds.

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

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

Since we have all the information while lowering, always
add the lowerbound, upperbound and stride information for acc.bounds
create from the Flang frontend.

Reviewed By: razvanlupusoru, jeanPerier

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

We previously changed this to use `nolibc` to allow it to link in
compiler builtins for the CPU build. However, these options are unused
on the GPU and create a lot of noise. Furthermore, we want to use
`nogpulib` to prevent the linking in of the vendor libraries.

Reviewed By: sivachandra

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

This patch updates the `__support` unit tests to be built as hermetic
tests. The only tests we needed to disable were because of the use of
`realloc` which is not implemented correctly as it doesn't copy the
memory.

Depends on D149745

Reviewed By: sivachandra

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

The FPEceptMatcher.cpp file uses system utilities and includes C++
libraries. This patch pulls it out of the main `FPTestHelpers` target so
we can exclude it from hermetic only tests.

Depends on D149705

Reviewed By: sivachandra

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

This changes the `stdlib` tests to the new `add_libc_test` framework.
This applies to all but the exit tests.

Depends on D149691

Reviewed By: sivachandra, michaelrj

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

Reviewed By: ldionne, #libc

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

Using pthread may affect the compilation too not only the linking.
Therefore pthread is changed from a link flag to a generic flag used for
both compilation and linking.

This fixes an issue when using modules since the use of the pthread flag
makes the BMI files not compatible.

Reviewed By: #libc, ldionne

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

Reviewed By: #libc, ldionne

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

std::bind is supposed to be constexpr-friendly since C++20 and it was
marked as such in our synopsis. However, the tests were not actually
testing any of it and as it happens, std::bind was not really constexpr
friendly. This fixes the issue and makes sure that at least some of the
tests are running in constexpr mode.

Some tests for std::bind check functions that return void, and those
use global variables. These tests haven't been made constexpr-friendly,
however the coverage added by this patch should be sufficient to get
decent confidence.

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

They are not failing on local Docker images, so something must be wrong
with our GCE instances.

If LHS is of derived type that needs initialization, then it must be
initialized before doing the assignment. Otherwise, the assignment
might behave incorrectly based on uninitialized components that are
descriptors themselves.

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

Alive2 links:
    eq: https://alive2.llvm.org/ce/z/Fv3mvc
    ne: https://alive2.llvm.org/ce/z/AEuEXU
    sle: https://alive2.llvm.org/ce/z/mfKGUS
    sge: https://alive2.llvm.org/ce/z/tX3_M4
    sgt: https://alive2.llvm.org/ce/z/x7VgnZ
    slt: https://alive2.llvm.org/ce/z/rQN4TM

Reviewed By: nikic

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

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

This reverts commit f9c1ede2.

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

This reverts commit 5b386b86.

Causes noticeable size increases under -Oz.

As of https://reviews.llvm.org/D79708, clang-tblgen generates `arm_neon.h`,
`arm_sve.h` and `arm_bf16.h`, and all those generated files will contain a
typedef of `bfloat16_t`. However, `arm_neon.h` and `arm_sve.h` include
`arm_bf16.h` immediately before their own typedef:

    #include <arm_bf16.h>
    typedef __bf16 bfloat16_t;

With a recent version of clang (I used 16.0.1) this results in warnings:

    /usr/lib/clang/16/include/arm_neon.h:38:16: error: redefinition of typedef 'bfloat16_t' is a C11 feature [-Werror,-Wtypedef-redefinition]

Since `arm_bf16.h` is very likely supposed to be the one true place where
`bfloat16_t` is defined, I propose to delete the duplicate typedefs from the
generated `arm_neon.h` and `arm_sve.h`.

Reviewed By: sdesmalen, simonbutcher

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

Accidental error.

This reverts commit 2e823da8.

This reverts commit 40ed87a0.

Instead of checking if the given bitwidth is less or equal to a bitwidth of an existing RegClass,
check if it has the exact same value.

For LLVM vector types that don't have a corresponding Register Class, widen them during legalization.
That goes for G_EXTRACT_VECTOR_ELT, G_INSERT_VECTOR_ELT and G_BUILD_VECTOR.

Differential revision: https://reviews.llvm.org/D148096
Reviewers: foad, arsenm

This reverts commit b25c7caf.

Per discussion at
https://discourse.llvm.org/t/representing-buffer-descriptors-in-the-amdgpu-target-call-for-suggestions/68798,
we define two new address spaces for AMDGCN targets.

The first is address space 7, a non-integral address space (which was
already in the data layout) that has 160-bit pointers (which are
256-bit aligned) and uses a 32-bit offset. These pointers combine a
128-bit buffer descriptor and a 32-bit offset, and will be usable with
normal LLVM operations (load, store, GEP). However, they will be
rewritten out of existence before code generation.

The second of these is address space 8, the address space for "buffer
resources". These will be used to represent the resource arguments to
buffer instructions, and new buffer intrinsics will be defined that
take them instead of <4 x i32> as resource arguments. ptr
addrspace(8). These pointers are 128-bits long (with the same
alignment). They must not be used as the arguments to getelementptr or
otherwise used in address computations, since they can have
arbitrarily complex inherent addressing semantics that can't be
represented in LLVM. Even though, like their address space 7 cousins,
these pointers have deterministic ptrtoint/inttoptr semantics, they
are defined to be non-integral in order to prevent optimizations that
rely on pointers being a [0, [addr_max]] value from applying to them.

Future work includes:
- Defining new buffer intrinsics that take ptr addrspace(8) resources.
- A late rewrite to turn address space 7 operations into buffer
intrinsics and offset computations.

This commit also updates the "fallback address space" for buffer
intrinsics to the buffer resource, and updates the alias analysis
table.

Depends on D143437

Reviewed By: arsenm

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

This reverts commit 069f027e.

Widen the vector operand type in G_BUILD_VECTOR, G_INSERT_VECTOR_ELT,
G_EXTRACT_VECTOR_ELT to the nearest larger RegClass.

Update kills in one place that was missed. Fixes a test failure that
would otherwise be introduced by D149651.

Some configurations flags are always the same. We can just remove them to make the code a bit cleaner.

Reviewed By: ldionne, #libc

Spies: pcwang-thead, libcxx-commits, miyuki

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