This is the failure:
https://lab.llvm.org/buildbot/#/builders/236/builds/7728/steps/10/logs/stdio

This started with eef8e1d2, but because
there were a couple of patches that came after that I had to revert all
3 of them because of merge conflicts.

Add a style option to specify the order that property attributes should
appear in ObjC property declarations (property attributes are things like
`nonatomic, strong, nullable`).

Closes #71323.

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

This check was trying to find cases of invalid API usage:
incorrect/missing handle side effects and/or incorrect rewriter usage.

This check is not implemented correctly and can report false positives
in case of pointer reuse (different op created at same location). It is
unclear if such a check can be implemented given that we have both
tracking listener-based handle updates and handle consumption.

Fixes #72931.

Without folding the result of the initial tensor.dim, the
ReifyResultShapes implementation would be incorrect because it would
return a dynamic shape for a static result shape.

This moves the offload entry logic into classes and provides convenient
accessors. No functional change intended but we can now print all
offload entries (and later look them up), tested via
`OMPTARGET_DUMP_OFFLOAD_ENTRIES=<device_no>`.

When building debug version of LLVM with
`LLVM_USE_RELATIVE_PATHS_IN_FILES=On` would cause source paths to be
incorrect, and be prefixed by the build directory. This lead to source
locations like the following: `../build/llvm/...`. Such paths do not
exist, and existing debuggers can't adjust their search location because
of the incorrect prefix. Ultimately, this happened because the relative
path creation goes in the wrong direction, from source-dir to build-dir
instead of from build-dir to source-dir.

This patch swaps the directionality of the relative paths so that they
get a proper prefix from the build directory. Given a build dir at
`/build` and a project directory at `/llvm-project`, we get source
locations like: `../llvm-project/llvm/lib/Transforms/...`, which a
debugger can resolve once pointed to the correct project directory.

This is not completely NFC since we now check all 4 requirements and the
test is checking the good and the bad case for combining flags.

`realloc` may involve both allocation and deallocation. Given that the
reporting the events is not atomic and which may lead the hook user to a
false case that the double-use pattern happens, we always report the old
pointer is released and report the new allocation afterward (even it's
the same pointer).

This also fixes that we didn't report the new size when it doesn't need
to allocate a new space.

This reverts commit 481e9b3e.

Breaks sanitizer bots: https://lab.llvm.org/buildbot/#/builders/127/builds/59071

So that when mixing small and large text, large text stays out of the
way of the rest of the binary.

This is useful for mixing precompiled small code model object files and
built-from-source large code model binaries so that the the text
sections don't get merged.

The reland fixes an issue where a function in the large code model would reference small data without GOTOFF.

This was incorrectly reverted in 76f78ecc.

Presumably this was done to make it similar to the getCalleeSavedRegs
list in RegInfo, but its simpler to use a range based for loop over the
array.

Treat ctor/dtor in device var init as host device function
so that they can be used to initialize file-scope
device variables to match nvcc behavior. If they are non-trivial
they will be diagnosed.

We cannot add implicit host device attrs to non-trivial
ctor/dtor since determining whether they are non-trivial
needs to know whether they have a trivial body and all their
member and base classes' ctor/dtor have trivial body, which
is affected by where their bodies are defined or instantiated.

Fixes: #72261

Fixes: SWDEV-432412

HIP toolchain uses llvm-mc to generate a host object embedding device
binary for -fgpu-rdc. Due to lack of .note.GNU-stack section, the
generated relocatable has executable stack marking, which disables
protection from executable stack for any HIP programs compiled with
-fgpu-rdc.

This patch adds .note.GNU-stack section to the input to llvm-mc to fix
the executable stack marking.

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

The `conv_2d_ngchw_fgchw` Op implements 2d grouped convolution with
dimensions ordered as given in the name. However, the current
implementation orders weights as `gfchw` instead of `fgchw`. This was
already pointed out in an old phabricator revision which never landed:
https://reviews.llvm.org/D150064

This patch
1) Adds a new op `conv_2d_ngchw_gfchw`
2) Fixes the dimension ordering of the old op `conv_2d_ngchw_fgchw`
3) Adds tests with non-dynamic dimensions so that it's easier to
  understand.

FreeBSD 10.x and 11.x support has been dropped leaving 12.x as the
minimum version. This FreeBSD check can be simplified.


https://github.com/llvm/llvm-project/commit/812dad536ed50abe94d6e2b2519f351791c24c59

The register class for the PADDI definition is incorrect as register
zero for RA is treated as an actual zero.

Patch 4b1fe097 introduced a bug when
building libc++ for Fuchsia, it disabled the libc++.so linker script by
default. This patch restores its original behavior.

This diff removes JumpInfo related code that is no longer needed by
CDSplit from SplitFunctions.cpp.

This adds an operation for concatenating ranked tensors along a static
dimension, as well as a decomposition mirroring the existing lowering
from TOSA to Tensor. This offers a convergence point for "input" like
dialects that include various lowerings for concatenation operations,
easing later analysis. In the future, this op can implement the
necessary interfaces for tiling, as well as potentially add conversions
to some kind of linalg and/or memref counterpart.

This patch adds the op, the decomposition, and some basic
folding/canonicalization. Replacing lowerings with the op (such as the
TOSA lowering) will come as a follow up.

See
https://discourse.llvm.org/t/rfc-tensor-add-a-tensor-concatenate-operation/74858

When 'ContinueOnCuIndexOverflow' enables without this modification, the
forcibly generated '.dwp' won't be recognized by Debugger(gdb 10.1)
correctly.
<img width="657" alt="image"
src="https://github.com/llvm/llvm-project/assets/150100070/31732775-2548-453a-a47a-fa04c6d05fe9">
it looks like there's a problem with processing the dwarf header, which
makes debugging completely impossible. (unless the consumer walks the debug_info section to rebuild that column (if that's the only section that overflowed - if it's another section, there's no recovery))

**About patch:**
When llvm-dwp enables option '--continue-on-cu-index-overflow=soft-stop'
and recognizes the overflow problem , it will stop packing and generate
the '.dwp' file at once, discarding any DWO files that would not fit
within the 32 bit/4GB limits of the format.
<img width="625" alt="image"
src="https://github.com/llvm/llvm-project/assets/150100070/77d6be24-262b-4f4c-afc0-9a6c49e133c7">

Migrated from: https://reviews.llvm.org/D155879

, with some of the
suggestions applied.

PR Description copied from above:

Currently asan simply exports each overridden new/delete function from
the DLL, this works fine normally, but fails if the user is overriding
some, but not all, of these functions. In this case the non-overridden
functions still come from the asan DLL, but they can't correctly call
the user provided override (for example sized op delete should fall back
to scalar op delete, if a scalar op delete is provided). Things were
also broken in the static build because all the asan overrides were
exported from the same TU, and so if you overrode one but not all of
them then you'd get ODR violations. This PR should fix both of these
cases, but the static case isn't really tested (and indeed one such test
does fail) because linking asan statically basically doesn't work on
windows right now with LLVM's version of asan. In fact, while we did fix
this in our fork, it was a huge mess and we've now made the dynamic
version work in all situations (/MD, /MT, /MDd, /MTd, etc) instead.

The following is the description from the internal PR that implemented
most of this feature.

> Previously, operator new/delete were provided as DLL exports when
linking dynamically and wholearchived when linked statically. Both
scenarios were broken. When linking statically, the user could not
define their own op new/delete, because they were already brought into
the link by ASAN. When dynamically linking, if the user provided some
but not all of the overloads, new and delete would be partially hooked.
For example, if the user defined scalar op delete, but the program then
called sized op delete, the sized op delete would still be the version
provided by ASAN instead of falling back to the user-defined scalar op
delete, like the standard requires.

> The change <internal PR number>: ASAN operator new/delete fallbacks in
the ASAN libraries fixes this moving all operator new/delete definitions
to be statically linked. However, this still won't work if
/InferAsanLibs still whole-archives everything since then all the op
new/deletes would always be provided by ASAN, which is why these changes
are necessary.

> With these changes, we will no longer wholearchive all of ASAN and
will leave the c++ parts (the op new/delete definitions) to be included
as a default library. However, it is also necessary to ensure that the
asan library with op new/delete will be searched before the
corresponding CRT library with the same op new/delete definitions. To
accomplish this, we make sure to add the asan library to the beginning
of the default lib list, or move it explicitly to the front if it's
already in the list. If the C runtime library is explicitly provided, we
make sure to warn the user if the current linker line will result in
operator new/delete not being provided by ASAN.

Note that the rearrangement of defaultlibs is not in this diff.

---------

Co-authored-by: Charlie Barto <Charles.Barto@microsoft.com>

Fix nvptx autoupdater's intrinsic matcher's typo'd names that used `_` (underbar), rather than '.' (dot), as a separator.

Check atomic prefix before looking for atomic instructions

Summary:
This pointer has been causing issues. Allocating and reading from coarse
memory on the CPU is not guaranteed and varies depending on the kernel
version and support. Previously we attempted to pin the memory but this
caused unexpected failures. This should be a legal operation and work
around the problem as fine-grained memory should be always legal to
write to by both sides.

This change is needed for changes I'm working on that allow
github workflows to build, push, and otherwise manage the container
images they use

A large amount of complexity when it comes to shuffling DPValue objects
around is pushed into BasicBlock::spliceDebugInfo, and it gets
comprehensive testing there via the unit tests. It turns out that there's a
corner case though: splicing instructions and debug-info to the end()
iterator requires blocks of DPValues to be concatenated, but the DPValues
don't behave normally as they're dangling at the end of a block. While this
splicing-to-an-empty-block case is rare, and it's even rarer for it to
contain debug-info, it does happen occasionally.

Fix this by wrapping spliceDebugInfo with an outer layer that removes any
dangling DPValues in the destination block -- that way the main splicing
function (renamed to spliceDebugInfoImpl) doesn't need to worry about that
scenario. See the diagram in the added function for more info.

A zero-length StringRef can have a null data pointer, which, if passed to the llvm_regex functions which take a pointer+length, but then convert it into a [begin, end) pointer pair can cause a nullptr+0 expression to be evaluated, which is UB. So avoid that by ensuring the data pointer is always non-null, even in the zero-length case.

Currently we emit gathers for scalars being vectorized in the tree as
a pair of extractelement/insertelement instructions. Instead we can try
to find all required vectors and emit shuffle vector instructions
directly, improving the code and reducing compile time.

Part of non-power-of-2 vectorization.

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

We can use neg+max or negw+max.

If we can infer statically that there are no incomplete tiles, we can
remove the optional padding operand.

Fixes https://github.com/openxla/iree/issues/15417