A subtle bug in buffer management is being caused by a WRITE on an
unformatted file with variable-length records after one or more
BACKSPACEs and some READs. An attempt at a minor optimization in
BACKSPACE kept the footer of the previous record in the unit's buffer,
in case more BACKSPACEs were to follow. If a later WRITE takes place
instead, the buffer's frame would still cover that footer, but its
content would be lost when the buffer became dirty on its first
modification, and the footer in the file would be overwritten with stale
buffer contents. As WriteFrame() implies the intent to define all the
bytes in the identified range, the trick being used in BACKSPACE with
its adjustment to frameOffsetInFile_ breaks any later WRITE... and so we
just can't do it.

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

This reverts commit cb13e928.
Buildbot reports MSAN failures in tests added in this commit:
https://lab.llvm.org/buildbot/#/builders/5/builds/38806

Failing tests:
  LLVM :: CodeGen/BPF/preserve-static-offset/load-arr-pai.ll
  LLVM :: CodeGen/BPF/preserve-static-offset/load-ptr-pai.ll
  LLVM :: CodeGen/BPF/preserve-static-offset/load-struct-pai.ll
  LLVM :: CodeGen/BPF/preserve-static-offset/load-union-pai.ll
  LLVM :: CodeGen/BPF/preserve-static-offset/store-pai.ll

…arrays

When comparing dummy array extents, cope with references to symbols
better (including references to other dummy arguments), and emit
warnings in dubious cases that are not equivalent but not provably
incompatible.

These tests are currently failing and their fix is being tracked in
Issue #60133. Marking them as XFAIL for now will get the test suite to a
passing state so we can work on adding a GitHub action to automatically
run these tests on a PR bot to help keep the tree green.

Also removed the no-longer supported -opaque-pointers=0 flag from the
couple tests where it was remaining.

Previously the type of the breakpoint id in the Stopped event was a
uint64_t, however thats the wrong type for a breakpoint id, which can
cause encoding issues when internal breakpoints are hit.

Opaque ptr cleanup effort (NFC).

This reverts commit 169db80e.

This change is causing many test failures on Windows bots:
- https://lab.llvm.org/buildbot/#/builders/235/builds/3616
- https://lab.llvm.org/buildbot/#/builders/233/builds/4883
- https://lab.llvm.org/buildbot/#/builders/216/builds/31174

The implementation of the predicate evaluate::IsVariable() needs to
recognize procedure pointers and return a false result for them.

If a suspend happens in the resume part (this can happen in the case of chained coroutines), and that's part of a loop, the pre-split CFG has the suspend block as an exit of that loop. PGO Counter Promotion will then try to commit the temporary counter to the global in that "exit" block (it also does that in the other loop exit BBs, which also includes
the "destroy" case). This interferes with symmetric transfer.

We don't need to commit the counter in the suspend case - it's not a loop exit from the perspective of the behavior of the program. The regular loop exit, together with the "destroy" case, completely cover any updates that may need to happen to the global counter.

Summary:
This portion of code handles mapping the RPC client memory over to the
device. HSA copies need to be between two slices of memory that HSA has
allocated. Previously we used coarse-grained memory to act as the host
source. However, the support for this varies depending on the kernel and
version and should not be relied upon. This patch changes that handling
to use the `hsa_amd_memory_lock` API to explicitly pin memory to a
location sufficient for a DMA transfer to the GPU.

Move the code to check the arguments of references to the intrinsic
function REDUCE() into Semantics/check-calls.cpp, and add checks for
several requirements from the standard that weren't yet caught.

so that we get an `error: unsupported option '-nopie' for target ...` instead of a warning.

The idea is similar to vector.maskedload + vector.store emulation. What
the emulation does is:

1. Get a compressed mask and load the data from destination.
2. Bitcast the data to original vector type.
3. Select values between `op.valueToStore` and the data from load using
original mask.
4. Bitcast the new value and store it to destination using compressed
masked.

PR #69473 introduced skipping PP directives when determining the brace
kind of an lbrace. However, it did so by skipping to the end of the line
when encountering a hash character. This means it also skipped to the
end of line when encountering a macro stringizing operator, which,
unlike PP directives, don't have effect until the end of line.

This led to cases where the rbrace could be completely skipped if it was
on the same line as a stringizing operator.

This patch skips hash characters if we're already in a PP directive, as
you can't define a macro inside of a macro

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

When applying ICHAR/IACHAR to a character constant with length greater
than one, resize the character constant to its first character.

Implement `mincore` as specified in
https://man7.org/linux/man-pages/man2/mincore.2.html

Co-authored-by: Ivan Radanov Ivanov <ivanov2@llnl.gov>

Clean-up towards removing method Type::getPointerTo.

The compiler will now emit an error for length == 0 and an
off-by-default portability warning for length > 1. Previously, the
message was an unconditional warning for length /= 1.

Checks for CUDA Fortran data attribute compatibility don't need to be
applied in OpenACC regions.

Generic code is supposed to handle this but can be blocked by hasOneUse checks.

Noticed while investigating #26392

Without the predicate there's no benefit to using the DQI variants instead of the default AVX512F instructions

Dead store elimination pass may fold malloc + memset calls into a single
call to calloc. If calloc is not preserved and is not being called
it can be marked dead which results in link error.

MIRBuilder already tells the observer when an instruction is created.

No other legalizer code on any target tells the observer when it
erases the instruction it was asked to legalize.

This reverts commit a4d5fd4d.

The above commit breaks greendragon lldb bots:
Link to failing builds:
https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/63300/
https://green.lab.llvm.org/green/view/LLDB/job/as-lldb-cmake/10345/

I found this PR to be the offending one after using git bisect with the
cmake invocation:

cmake -G Ninja ../llvm -DCMAKE_BUILD_TYPE=Release
-DCMAKE_EXPORT_COMPILE_COMMANDS=ON
'-DLLVM_TARGETS_TO_BUILD=X86;ARM;AArch64'
-DLLVM_ENABLE_ASSERTIONS:BOOL=TRUE
-DLLVM_ENABLE_MODULES=On
-DLLVM_ENABLE_PROJECTS='clang;lld;lldb;cross-project-tests'
-DLLVM_VERSION_PATCH=99
'-DLLVM_ENABLE_RUNTIMES=libcxx;libcxxabi;compiler-rt'

and running
ninja lib/CodeGen/CMakeFiles/LLVMCodeGen.dir/CodeGenPassBuilder.cpp.o

Currently when you interrupt a:

(lldb) process attach -w -n some_process

lldb just closes the connection to the stub and kills the
lldb_private::Process it made for the attach. The stub at the other end
notices the connection go down and exits because of that. But when
communication to a device is handled through some kind of proxy server
which isn't as well behaved as one would wish, that signal might not be
reliable, causing debugserver to persist on the machine, waiting to
steal the next instance of that process.

We can work around those failures by sending an explicit interrupt
before closing down the connection. The stub will also have to be
waiting for the interrupt for this to make any difference. I changed
debugserver to do that.

I didn't make the equivalent change in lldb-server. So long as you
aren't faced with a flakey connection, this should not be necessary.

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

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

This adds code to AArch64 function prologues to protect against stack
clash attacks by probing (writing to) the stack at regular enough
intervals to ensure that the guard page cannot be skipped over.

The patch depends on and maintains the following invariants:

Upon function entry the caller guarantees that it has probed the stack
(e.g. performed a store) at some address [sp, #N], where`0 <= N <=
1024`. This invariant comes from a requirement for compatibility with
GCC. Any address range in the allocated stack, no smaller than
stack-probe-size bytes contains at least one probe At any time the stack
pointer is above or in the guard page Probes are performed in
descreasing address order
The stack-probe-size is a function attribute that can be set by a
platform to correspond to the guard page size.

By default, the stack probe size is 4KiB, which is a safe default as
this is the smallest possible page size for AArch64. Linux uses a 64KiB
guard for AArch64, so this can be overridden by the stack-probe-size
function attribute.

For small frames without a frame pointer (<= 240 bytes), no probes are
needed.

For larger frame sizes, LLVM always stores x29 to the stack. This serves
as an implicit stack probe. Thus, while allocating stack objects the
compiler assumes that the stack has been probed at [sp].

There are multiple probing sequences that can be emitted, depending on
the size of the stack allocation:

A straight-line sequence of subtracts and stores, used when the
allocation size is smaller than 5 guard pages. A loop allocating and
probing one page size per iteration, plus at most a single probe to deal
with the remainder, used when the allocation size is larger but still
known at compile time. A loop which moves the SP down to the target
value held in a register (or a loop, moving a scratch register to the
target value help in SP), used when the allocation size is not known at
compile-time, such as when allocating space for SVE values, or when
over-aligning the stack. This is emitted in AArch64InstrInfo because it
will also be used for dynamic allocas in a future patch. A single probe
where the amount of stack adjustment is unknown, but is known to be less
than or equal to a page size.

---------

Co-authored-by: Oliver Stannard <oliver.stannard@linaro.org>

When option --dwarf-output-path is specified, if the path does not exist
BOLT will now create it. This is what also happens when
--plugin-opt=dwo_dir=<value> is specified to LLD.

This centralizes all COO methods, and provides a cleaner API. Note that
the "enc" only constructor is a temporary workaround the need for COO
methods inside the "enc" only storage specifier.

This patch converts (almost) every expected directive in `test/CXX/drs/dr0xx.cpp` into either `@-1` form (when directive immediately follow the line diagnostic is pointing out to), or `@#<marker>` form (when directive is placed away from the line diagnostic is pointing out to). It also converts directive to match exactly one diagnostic, as opposed to matching multiple. Error messages are expanded to exactly match compiler output. `#if __cplusplus` guarding directives are replaced with respective prefixes (e.g. `since-cxx17`).

All aforementioned changes serve a purpose of making it easier to reconstruct expected compiler output, which should also make it a bit easier to grasp the gist of those already non-trivial tests due to their nature of testing corner cases of the language.

This is based of the varargs coe in RISCVTargetLowering::LowerFormalArguments.

The legalization was modeled after SelectionDAG.

The base change here is to change getMemOperandWithOffsetWidth to return
a TypeSize Width, which in turn allows areMemAccessesTriviallyDisjoint
to reason about trivially disjoint widths.

This is done in instruction-select instead of in legalization for the
sake of alias analysis.

…[UN]MERGE_VALUES

When MERGE or UNMERGE s64 on a subtarget that is non-64bit, it must have
the D extension and use FPR in order to be legal.

All other instances of MERGE and UNMERGE that can be made legal should
be narrowed, widend, or replaced by the combiner.

This is similar to the selection of G_IMPLICIT_DEF in AArch64.
Regbankselect may need to be improved in a future patch.