Created using spr 1.3.4

[skip ci]

XCore does not appear to have any support for atomicrmw or cmpxchg.

This will result in all atomic operations getting expanded to __atomic_*
libcalls via AtomicExpandPass, which matches what Clang already does in
the frontend.

Additionally, remove the code which handles atomic load/store, as it
will no longer be used.

The Process JITDylib holds reflected process symbols. The Platform JITDylib
holds ORC runtime symbols if the ORC runtime is loaded. The Platform and
Process JITDylibs are appended to the link order of all other JITDylibs,
including the main JITDylib, after any explicitly specified libraries. This
scheme is similar to the one introduced in LLJIT in 371cb1af, and makes
it easier to introduce aliases for process and platform symbols in a way that
affects all JITDylibs uniformly.

Since the Process and Platform JITDylibs are created implicitly the -alias
option is generalized to allow source and destination JITDylibs to be explicitly
specified, i.e. the -alias option now supports general re-exports.

Testcases are updated to account for the change.

This reverts commit 34cdc913.

Two buildbots say this is bad:

  https://lab.llvm.org/buildbot/#/builders/265/builds/861
  https://lab.llvm.org/buildbot/#/builders/168/builds/17272

Removed obsoleted TODOs and NOTEs, formatting, removed unused parameter

This commit adds a new BPF specific structure attribte
`__attribute__((preserve_static_offset))` and a pass to deal with it.

This attribute may be attached to a struct or union declaration, where
it notifies the compiler that this structure is a "context" structure.
The following limitations apply to context structures:
- runtime environment might patch access to the fields of this type by
  updating the field offset;

  BPF verifier limits access patterns allowed for certain data
  types. E.g. `struct __sk_buff` and `struct bpf_sock_ops`. For these
  types only `LD/ST <reg> <static-offset>` memory loads and stores are
  allowed.

  This is so because offsets of the fields of these structures do not
  match real offsets in the running kernel. During BPF program
  load/verification loads and stores to the fields of these types are
  rewritten so that offsets match real offsets. For this rewrite to
  happen static offsets have to be encoded in the instructions.

  See `kernel/bpf/verifier.c:convert_ctx_access` function in the Linux
  kernel source tree for details.

- runtime environment might disallow access to the field of the type
  through modified pointers.

  During BPF program verification a tag `PTR_TO_CTX` is tracked for
  register values. In case if register with such tag is modified BPF
  programs are not allowed to read or write memory using register. See
  kernel/bpf/verifier.c:check_mem_access function in the Linux kernel
  source tree for details.

Access to the structure fields is translated to IR as a sequence:
- `(load (getelementptr %ptr %offset))` or
- `(store (getelementptr %ptr %offset))`

During instruction selection phase such sequences are translated as a
single load instruction with embedded offset, e.g. `LDW %ptr, %offset`,
which matches access pattern necessary for the restricted
set of types described above (when `%offset` is static).

Multiple optimizer passes might separate these instructions, this
includes:
- SimplifyCFGPass (sinking)
- InstCombine (sinking)
- GVN (hoisting)

The `preserve_static_offset` attribute marks structures for which the
following transformations happen:
- at the early IR processing stage:
  - `(load (getelementptr ...))` replaced by call to intrinsic
    `llvm.bpf.getelementptr.and.load`;
  - `(store (getelementptr ...))` replaced by call to intrinsic
    `llvm.bpf.getelementptr.and.store`;
- at the late IR processing stage this modification is undone.

Such handling prevents various optimizer passes from generating
sequences of instructions that would be rejected by BPF verifier.

The __attribute__((preserve_static_offset)) has a priority over
__attribute__((preserve_access_index)). When preserve_access_index
attribute is present preserve access index transformations are not
applied.

This addresses the issue reported by the following thread:

https://lore.kernel.org/bpf/CAA-VZPmxh8o8EBcJ=m-DH4ytcxDFmo0JKsm1p1gf40kS0CE3NQ@mail.gmail.com/T/#m4b9ce2ce73b34f34172328f975235fc6f19841b6

This is a second attempt to commit this change, previous reverted
commit is: cb13e928.
The following items had been fixed:
- test case bpf-preserve-static-offset-bitfield.c now uses
  `-triple bpfel` to avoid different codegen for little/big endian
  targets.
- BPFPreserveStaticOffset.cpp:removePAICalls() modified to avoid
  use after free for `WorkList` elements `V`.

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

This causes current mainline to now report "18.0.0git" instead of
"18.0.0".

Fixes #53825

Following up the discussion at
https://github.com/llvm/llvm-project/pull/73469#discussion_r1409593911
by @nickdesaulniers.

According to FreeBSD implementation
(https://android.googlesource.com/platform/bionic/+/refs/heads/main/libc/upstream-freebsd/lib/libc/stdlib/hcreate.c),
`hsearch` is able to handle the cases where the global table is not
properly initialized. To do this, FreeBSD actually allows hash table to
be dynamically resized. If the global table is uninitialized at the
first call, the table will be initialized with a minimal size; hence
subsequent insertion will be reasonable as the table grows
automatically.

This patch mimic such behaviors. More precisely, this patch introduces:

1. a full table iterator that scans each element in the table,
2. a resize routine that is automatically triggered whenever the load
factor is reached where it iterates the old table and insert the entries
into a new one,
3. more tests that cove...

This patch is fixing two issue relative to the dynamic dispatch for
polymorphic entities.

1. Fix the `requireDispatchCall` function. It was checking for the first
symbol of the component but this is not the one to be checked. Instead
the last symbol of the base of the component object is the one to check
to know if it is polymorphic object with a dispatch call or not. This is
demonstrated in the new added test in `flang/test/Lower/dispatch.f90`
where the first symbol would point to `q` which is monomorphic and would
result in a simple `fir.call`
2. Fix the pass object in a no pass situation. In a no pass situation
the pass object is lowered anyway to be able to do the lookup in the
binding table. It was previously lowered wrongly an lead to unresolved
lookup. The base of the component is the passed object and should be
lowered. To achieve this, the `gen(DataRef)` entry point is exposed form
`ConvertExprToHLFIR` through a `convertDataRefToValue` function. The
same test added in `flang/test/Lower/dispatch.f90` is checking for the
correct passed object.

In addition couple of tests were updated to HLFIR since the lowering
used only works with it.

We're removing trailing debug-records at the correct time, but from the
wrong block. Broken the iterators buildbot:

  https://lab.llvm.org/buildbot/#/builders/275/builds/1889

CodeGen options do not affect the AST, so they usually can be ignored.
The only exception to the rule is when a PCM is created with
`-gmodules`.
In that case the Clang module format is switched to object file
container and contains also serialized debug information that can be
affected by debug options. There the following approach was choosen:

1.) Split out all the debug options into a separate `DebugOptions.def`
    file. The file is included by `CodeGenOptions.def`, so the change is
    transparent to all existing users of `CodeGenOptions.def`.
2.) Reset all CodeGen options, but excluding affecting debug options.
3.) Conditionally reset debug options that can affect the PCM.

This fixes rdar://113135909.

`-arch` is a Darwin-specific option that is ignored for other targets
and not known by GCC.
```
% clang -arch arm64 -c a.c
clang: warning: argument unused during compilation: '-arch arm64' [-Wunused-command-line-argument]
```

We are utilizing TargetSpecific (from https://reviews.llvm.org/D151590)
to make more options lead to errors for unsupported targets.

Globals marked with the .lbss/.ldata/.lrodata should automatically be
treated as large.
Do this regardless of the code model for consistency when mixing object
files compiled with different code models.

Basically the other half of #70748.

Example in the wild:
https://codebrowser.dev/qt5/qtbase/src/testlib/qtestcase.cpp.html#1664

Found while running libc++'s tests with MSVC's STL, where `std::array`
iterators are never pointers.

Most of these changes are reasonably self-explanatory (the `std::array`s
are right there, and the sometimes-slightly-wrapped raw pointer types
are a short distance away). A couple of changes are less obvious:

In `libcxx/test/std/containers/from_range_helpers.h`, `wrap_input()` is
called with `Iter` types that are constructible from raw pointers. It's
also sometimes called with an `array` as the `input`, so the first
overload was implicitly assuming that `array` iterators are pointers. We
can fix this assumption by providing a dedicated overload for `array`,
just like the one for `vector` immediately below. Finally,
`from_range_helpers.h` should explicitly include both `<array>` and
`<vector>`, even though they were apparently being dragged in already.

In `libcxx/test/std/containers/views/views.span/span.cons/iterator_sentinel.pass.cpp`,
fix `throw_operator_minus`. The error was pretty complicated, caused by
the concepts machinery noticing that `value_type` and `element_type`
were inconsistent. In the template instantiation context, you can see
the critical detail that `throw_operator_minus<std::_Array_iterator>` is
being formed.

Fortunately, the fix is extremely simple. To produce `element_type`
(which retains any cv-qualification, unlike `value_type`), we shouldn't
attempt to `remove_pointer` with the iterator type `It`. Instead, we've
already obtained the `reference` type, so we can `remove_reference_t`.
(This is modern code, where we have access to the alias templates, so I
saw no reason to use the older verbose form.)

This patch gets call site splitting to use iterators for insertion
rather than instruction pointers. When we switch on non-instr debug-info
this becomes significant, as the iterators are going to signal whether
or not a position is before or after debug-info.

NFC as this isn't going to affect the output of any existing test.

As requested in https://github.com/llvm/llvm-project/pull/74482.

As part of the upcoming clang-formatting of libc++, this patch performs
the long desired removal of the _VSTD macro.

See https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all
for the clang-format proposal.

- Clang FE now has MaxAtomicPromoteWidth / MaxAtomicInlineWidth set to 128, and now produces IR
  instead of calls to __atomic instrinsics for 16 bytes as well.
- Atomic __int128 (and long double) variables are now aligned to 16 bytes by default (like gcc 14).
- AtomicExpand pass now expands 16 byte operations as well.
- tests for __atomic builtins for all integer widths, and __atomic_is_lock_free with friends.
- TODO: AtomicExpand pass handles with this patch expansion of i128 atomicrmw:s. As a next step
  smaller integer types should also be possible to handle this way instead of by the backend.

[P2017R1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2017r1.html#wording)
appears to have been implemented in LLVM 16.0:
https://godbolt.org/z/GbcT4rjcd.

Use the disjoint flag to convert or to add instead of calling the
haveNoCommonBitsSet() ValueTracking query. This ensures that we can
reliably undo add -> or canonicalization, even in cases where the
necessary information has been lost or is too complex to reinfer in
SCEV.

I have updated the bulk of the test coverage to add the necessary
disjoint flags in advance.

Instead of using VLENB and a shift, load (VLEN/8)*LMUL directly into a
register. We could go further and use ADDI, but that would be more
intrusive to the code structure.

My primary goal is to remove the read of VLENB which might be expensive
if it's not optimized in hardware.

We know we're splitting a type in half to two legal values. Instead of
using shift and truncate that need to be legalized, we can use two
ISD::EXTRACT_ELEMENTs.

Spotted while reviewing #67918 for RISC-V which copied this code.

Remove real 10 tests for powerpc

---------

Co-authored-by: Mark Danial <mark.danial@ibm.com>

In the debug-info-splice implementation, we need to be careful to delete
trailing DPMarkers from blocks when we splice their contents out. This
is equivalent to removing the terminator from a block, then splicing the
rest of it's contents to another block: any DPValues trailing at the end
of the block get moved and we need to clean up afterwards.

Fix another test I missed in 9e4210fa

As shown in #70473, the following loop was not considered safe to
vectorize. When determining the memory access dependencies in
a loop which has negative iteration step, we invert the source and
sink of the dependence. Perhaps we should just invert the operands
to getMinusSCEV(). This way the dependency is not regarded to be
true, since the users of the `IsWrite` variables, which correspond to
each of the memory accesses, rely on program order and therefore
should not be swapped.

void vectorizable_Read_Write(int *A) {
  for (unsigned i = 1022; i >= 0; i--)
    A[i+1] = A[i] + 1;
}

Summary:
The GPU tests tend to fail when run massively in parallel. This is why
we use a CMake job pool to limit it to 1 in most cases. We should
default to the configuration that is most likely to work, that being a
single thread. There aren't enough GPU tests for this to be a massive
increase in test time on the bots, so we should default to what works
guaranteed.

A new disjoint flag was added for OR instructions in #72583. 

Update VPRecipeWithIRFlags to also support the new flag. This
allows printing and preserving the disjoint flag in vectorized code.

...instead of the currently used, more abstract Location callback. The
main advantage of this change is that after it the checker will check
`array[index].field` while the previous implementation ignored this
situation (because here the ElementRegion is wrapped in a FieldRegion
object). This improvement fixes PR #70187.

Note that after this change `&array[idx]` will be handled as an access
to the `idx`th element of `array`, which is technically incorrect but
matches the programmer intuitions. In my opinion it's more helpful if
the report points to the source location where the indexing happens
(instead of the location where a pointer is finally dereferenced).

As a special case, this change allows code that forms the past-the-end
pointer of an array as `&arr[size]` (but still rejects code like
`if (idx >= size) return &array[idx];` and code that dereferences a
past-the-end pointer).

In addition to this primary improvement, this change tweaks the message
for the tainted index/offset case (using the more concrete information
that's available now) and clarifies/improves a few testcases.

The main change of this commit (replacing `check::Location` with
`check::PostStmt<...>` callbacks) was already proposed in my change
https://reviews.llvm.org/D150446 and https://reviews.llvm.org/D159107 by
steakhal. Those reviews were both abandoned, but the problems that led
to abandonment were unrelated to the change that is introduced in this
PR.

Also use ABI alignment for ptr sized objects.

This makes the code more sane and avoids only loading part of what was
stored by vastart on RV64.

Found while running libc++'s tests with MSVC's STL. This fixes 3 kinds of warnings:

- Add void-casts to fix `-Wunused-variable` warnings.
- Avoid sign/truncation warnings in `ConvertibleToIntegral.h`.
- Add `TEST_STD_AT_LEAST_23_OR_RUNTIME_EVALUATED` to avoid mixing preprocessor 
  and runtime tests.
- Cleanup: Add `TEST_STD_AT_LEAST_20_OR_RUNTIME_EVALUATED` for
  consistency.

Slightly more powerful if the information used to infer disjoint
was lost.

Compiler crashes when the assertion triggered for zext nneg instruction,
that checks that the instruction cannot produce poison. Changed the base
class for widencast recipe to handle dropping nneg flag to avoid
compiler crash.

Fix #69214 
In `emitOMPSimdRegion`, the `EmitOMPPrivateLoopCounters` should be after
`EmitOMPPrivateClause`.
If not, the private variables will be registered too early, which is not
allowed by `EmitOMPPrivateClause`.

Newlib's strerror function returns an empty string for unknown errnum
values as described in [1].

[1]: https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=newlib/libc/string/strerror.c;hb=HEAD

Use disjoint instead of haveNoCommonBitsSet(), which is slightly
stronger in case the information used to infer disjoint has been
lost.

Introduce the m_DisjointOr() matcher to make handling cases like
this cleaner.

We occasionally move instructions to their own positions, which is not
an error, and has no effect on the program. However, if dbg.value
intrinsics are present then they can effectively be moved without any
other effect on the program.

This is a problem if we're using non-instruction debug-info: a moveAfter
that appears to be a no-op in RemoveDIs mode can jump in front of
intrinsics in dbg.value mode. Thus: if an instruction is moved to itself
and the head bit is set, force attached debug-info to shift down one
instruction, which replicates the dbg.value behaviour.