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

Previously in D104261 we warned about dropping locks from back edges,
this is the corresponding change for exclusive/shared joins. If we're
entering the loop with an exclusive change, which is then relaxed to a
shared lock before we loop back, we have already analyzed the loop body
with the stronger exclusive lock and thus might have false positives.

There is a minor non-observable change: we modify the exit lock set of a
function, but since that isn't used further it doesn't change anything.

Reviewed By: aaron.ballman

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

(cherry picked from commit 9b889f82)

Currently, we use SExtValue to decide whether to invert tbz or tbnz.
However, for the case zext (xor x, c), we should use ZExt rather
than SExt otherwise we will generate totally opposite branches.

Reviewed By: paquette

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

(cherry picked from commit 5f48c144)

Add a release note for the renaming of the debuginfo-test to
cross-project-tests, performed in commit
1364750d and follow-ons.

Reviewed by: sylvestre.ledru

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

When searching for hidden identity shuffles (added at rG41146bfe), only peek through bitcasts to the source operand if it is a vector type as well.

(cherry picked from commit dcba9941)

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

(cherry picked from commit b588f5d6)

There needs to be a blank line after ".. code-block:: <lang>".

(cherry picked from commit 3db95906)

(cherry picked from commit 454f69bc)

After D94315 we add the `NoInline` attribute to the outlined function to handle
data environments in the OpenMP if clause. This conflicted with the `AlwaysInline`
attribute added to the outlined function. for better performance in D106799.
The data environments should ideally not require NoInline, but for now this
fixes PR51349.

Reviewed By: mikerice

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

(cherry picked from commit 41a6b50c)

9ee64c37 has started using
COMPILER_RT_HAS_OMIT_FRAME_POINTER_FLAG inside scudo.  However,
the relevant CMake check was performed in builtin-config-ix.cmake,
so the definition was missing when builtins were not built.  Move
the check to config-ix.cmake, so that it runs unconditionally of
the components being built.

Fixes PR#51847

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

(cherry picked from commit 210d72e9)

See PR51842.

This fixes an assert firing in the static analyzer, triggered by implicit moves
in blocks in C mode:

This also simplifies the AST a little bit when compiling non C++ code,
as the xvalue implicit casts are not inserted.

We keep and test that the nrvo flag is still being set on the VarDecls,
as that is still a bit beneficial while not really making anything
more complicated.

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>

Reviewed By: NoQ

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

(cherry picked from commit 2d6829bb)

This is essentially what D106813 was supposed to do but did not.

Differential revision: https://reviews.llvm.org/D108919

(cherry picked from commit c9948e92)

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

(cherry picked from commit 71052ea1)

Users of VPValues are managed in a vector, so we need to be more
careful when iterating over users while updating them. For now, just
copy them.

Fixes 51798.

(cherry picked from commit 368af755)

Commits 58494c85, f6bc6145, and 0fc27ef1 added special
handlings for K&R C function definitions and caused some
JavaScript/TypeScript regressions which were addressed in D107267,
D108538, and D108620. This patch would have prevented these known
regressions and will fix any unknown ones.

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

(cherry picked from commit 3205dd3d)

This patch fixes register save/restore on expression call to also include SVE registers.

This will fix expression calls like:

re re p1

<Register Value P1 before expression>

p <var-name or function call>

re re p1

<Register Value P1 after expression>

In above example register P1 should remain the same before and after the expression evaluation.

Reviewed By: DavidSpickett

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

This reverts commit 5cd63e9e.

https://bugs.llvm.org/show_bug.cgi?id=51707

Commit Message from @MaskRay:

Rust has a fragile embed-bitcode implementation
(https://github.com/rust-lang/rust/blob/bddb59cf07efcf6e606f16b87f85e3ecd2c1ca69/compiler/rustc_codegen_llvm/src/back/write.rs#L970-L1017)
which relied on the previous LLVM MC behavior.  Rust's LLVM fork
has carried a revert. This commit made the similar revert to help
distributions since they would otherwise probably carry a similar patch
(as they ship rust linked against system LLVM).

Fixes https://bugs.llvm.org/show_bug.cgi?id=51207.

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

This patch enables compressed input sections on big-endian targets by
checking the target endianness and selecting an appropriate `Chdr`
structure.

Fixes PR51369

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

(cherry picked from commit c6ebc651)

On X86, the stackprobe emission code chooses the `R11D` register, which
is illegal on i686.  This ends up wrapping around to `EBX`, which does
not get properly callee-saved within the stack probing prologue,
clobbering the register for the callers.

We fix this by explicitly using `EAX` as the stack probe register.

Reviewed By: pengfei

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

(cherry picked from commit ae8507b0)

If the constant is a constant expression, then getAggregateElement()
will return null. Guard against this before calling HasFn().

(cherry picked from commit af382b93)

[SimplifyCFG] performBranchToCommonDestFolding(): require block-closed SSA form for bonus instructions (PR51125)

I can't seem to wrap my head around the proper fix here,
we should be fine without this requirement, iff we can form this form,
but the naive attempt (https://reviews.llvm.org/D106317) has failed.
So just to unblock the release, put up a restriction.

Fixes https://bugs.llvm.org/show_bug.cgi?id=51125

(cherry picked from commit 909cba96)

Update a section of OpenCLSupport page to reflect the latest
development in OpenCL 3.0 support for release 13.

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

(cherry picked from commit cff03d5f)

Major OpenCL functionality added in release 13.

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

Reviewed By: cryptoad

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

(cherry picked from commit 9ee64c37)

Clean up the detection of parameter declarations in K&R C function
definitions. Also make it more precise by requiring the second
token after the r_paren to be either a star or keyword/identifier.

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

(cherry picked from commmit 643f2be7)

This is a follow-up to https://reviews.llvm.org/D107950 which
missed user-defined types in K&R C.

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

(cherry picked from commit f6928cf4)

After
https://github.com/llvm/llvm-project/commit/9da70ab3d43c79116f80fc06aa7cf517374ce42c
we saw a few regressions around trailing attribute definitions and in
typedefs (examples in the added test cases). There's some tension
distinguishing K&R definitions from attributes at the parser level,
where we have to decide if we need to put the type of the K&R definition
on a new unwrapped line before we have access to the rest of the line,
so we're scanning backwards and looking for a pattern like f(a, b). But
this type of pattern could also be an attribute macro, or the whole
declaration could be a typedef itself. I updated the code to check for a
typedef at the beginning of the line and to not consider raw identifiers
as possible first K&R declaration (but treated as an attribute macro
instead). This is not 100% correct heuristic, but I think it should be
reasonably good in practice, where we'll:
  * likely be in some very C-ish code when using K&R style (e.g., stuff
    that uses `struct name a;` instead of `name a;`
  * likely be in some very C++-ish code when using attributes
  * unlikely mix up the two in the same declaration.

Ideally, we should only decide to add the unwrapped line before the K&R
declaration after we've scanned the rest of the line an noticed the
variable declarations and the semicolon, but the way the parser is
organized I don't see a good way to do this in the current parser, which
only has good context for the previously visited tokens. I also tried
not emitting an unwrapped line there and trying to resolve the situation
later in the token annotator and the continuation indenter, and that
approach seems promising, but I couldn't make it to work without
messing up a bunch of other cases in unit tests.

Reviewed By: MyDeveloperDay

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

(cherry picked from commit 45934922)

A follow-up to
https://github.com/llvm/llvm-project/commit/f6bc614546e169bb1b17a29c422ebace038e6c62
where we handle the case where the semicolon is followed by a trailing
comment.

Reviewed By: MyDeveloperDay

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

(cherry picked from commit 0fc27ef1)

https://reviews.llvm.org/D105964 updated the detection of function
definitions. It had the unfortunate effect to start marking object
definitions with attribute-like macros as function definitions.

This addresses this issue.

Reviewed By: owenpan

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

(cherry picked from commit f6bc6145)

This patch fixes a variety of crashes resulting from the `MemCpyOptPass`
casting `TypeSize` to a constant integer, whether implicitly or
explicitly.

Since the `MemsetRanges` requires a constant size to work, all but one
of the fixes in this patch simply involve skipping the various
optimizations for scalable types as cleanly as possible.

The optimization of `byval` parameters, however, has been updated to
work on scalable types in theory. In practice, this optimization is only
valid when the length of the `memcpy` is known to be larger than the
scalable type size, which is currently never the case. This could
perhaps be done in the future using the `vscale_range` attribute.

Some implicit casts have been left as they were, under the knowledge
they are only called on aggregate types. These should never be
scalably-sized.

Reviewed By: nikic, tra

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

(cherry-picked from commit 7fb66d40)

Following nvptx approach, this patch uses complex function
definitions from complex_cmath.h. With this patch, ovo passes
23/34 complex mathematical test cases.

Reviewed By: JonChesterfield

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

(cherry picked from commit 12dcbf91)

When lowering a fixed length gather/scatter the index type is assumed to
be the same as the memory type, this is incorrect in cases where the
extension of the index has been folded into the addressing mode.

For now add a temporary workaround to fix the codegen faults caused by
this by preventing the removal of this extension. At a later date the
lowering for SVE gather/scatters will be redesigned to improve the way
addressing modes are handled.

As a short term side effect of this change, the addressing modes
generated for fixed length gather/scatters will not be optimal.

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

(cherry picked from commit 14e1a4a6)

As part of the nontrivial unswitching we could end up removing child
loops. This patch add a notification to the pass manager when
that happens (using the markLoopAsDeleted callback).

Without this there could be stale LoopAccessAnalysis results cached
in the analysis manager. Those analysis results are cached based on
a Loop* as key. Since the BumpPtrAllocator used to allocate
Loop objects could be resetted between different runs of for
example the loop-distribute pass (running on different functions),
a new Loop object could be created using the same Loop pointer.
And then when requiring the LoopAccessAnalysis for the loop we
got the stale (corrupt) result from the destroyed loop.

Reviewed By: aeubanks

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

(fixes PR51754)
(cherry-picked from commit 0f0344dd)

Setting -fvisibility=hidden when compiling Target libs has the advantage of
not being intrusive on the codebase, but it also sets the visibility of all
functions within header-only component like ADT. In the end, we end up with
some symbols with hidden visibility within llvm dylib (through the target libs),
and some with external visibility (through other libs). This paves the way for
subtle bugs like https://reviews.llvm.org/D101972

This patch explicitly set the visibility of some classes to `default` so that
`llvm::Any` related symbols keep a `default` visibility. Indeed a template
function with `default` visibility parametrized by a type with `hidden`
visibility is granted `hidden` visibility, and we don't want this for the
uniqueness of `llvm::Any::TypeId`.

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

Also fixes a warning mentioned in D109359.

Reviewed By: sdesmalen

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

(cherry picked from commit 89786c2b)

This causes https://bugs.llvm.org/show_bug.cgi?id=51714 and
is not a right patch according to comments in D91724

This reverts commit 42eaf4fe.

(cherry picked from commit 34badc40)

See PR48617.

When assigning the new template arguments to the new TypeLoc, we were looping
on the argument count of the original TypeLoc instead of the new one,
which can be different when packs are present.

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>

Reviewed By: rsmith

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

(cherry picked from commit 68b9d8ed)