Fixed some new memory leaks after migration to new
bufferization. One is expected, the other may need
some more careful analysis.

Reviewed By: jpienaar

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

Since the divergence-driven instruction selection has been enabled for AMDGPU,
 all the uniform instructions are expected to be selected to SALU form, except those not having one.
 VGPR to SGPR copies appear in MIR to connect values producers and consumers. This change implements an algorithm
 that evolves a reasonable tradeoff between the profit achieved from keeping the uniform instructions in SALU form
 and overhead introduced by the data transfer between the VGPRs and SGPRs.

Reviewed By: rampitec

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

-fembed-bitcode will put bitcode into special sections within object
files, but this is not meant to be used by LTO, so the gold plugin
should ignore it.

https://github.com/llvm/llvm-project/issues/47216

Reviewed By: tejohnson, MaskRay

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

This reverts commit d2460d90.

Reverting this commit because after pushing to main it caused
unexpected test failures.

Introducing the support for evaluating the constructor
of every element in an array. The idea is to record the
index of the current array member being constructed and
create a loop during the analysis. We looping over the
same CXXConstructExpr as many times as many elements
the array has.

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

Try the shared library first, and if it doesn't exist fallback onto
the static one. When the static library is requested, skip the shared
library.

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

On my system the date formatting is a bit different from what the test used to
support. I'm using:

  Windows 11 version 21H2, build 22000.795 using the English(Canada) region.
  ls from BusyBox 1.36
  VS 2022 17.2.5
  WinSDK 10.0.22000

After recent bufferization improvement, this test
started failing due to missed zero initialization.

Reviewed By: jpienaar

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

Reviewed By: #lld-macho, thakis

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

Add the collective subroutine, co_sum, to the list of intrinsics.
In accordance with 16.9.50 and 16.9.137, add a check for and an
error if coindexed objects are being passed to certain arguments
in co_sum and in move_alloc. Add a semantics test to check that
this error is successfully caught in calls to move_alloc. Remove
the XFAIL directive, update the ERROR directives and add both
standard-conforming and non-standard conforming calls to the
semantics test for co_sum.

Reviewed By: jeanPerier

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

Thanks to Alex Brachet for spotting it in D110217.

The lds_barrier op allows workgroups to wait at a barrier for
operations to/from their local data store (LDS) to complete without
incurring the performance penalties of a full memory fence.

Reviewed By: nirvedhmeshram

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

Reviewed By: michaelrj, lntue

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

As we are moving towards support for multiple fragments, loops that
iterate over all basic blocks of a function, but do not depend on the
order of basic blocks in the final layout, should iterate over binary
functions directly, rather than the layout.

Eventually, all loops using the layout list should either iterate over
the function, or be aware of multiple layouts. This patch replaces
references to binary function's block layout with the binary function
itself where only little code changes are necessary.

Reviewed By: maksfb

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

[libc++][ranges] implement `std::ranges::set_union`

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

D127650 removed support for non-clang-based XL compilers, but left some
of the headers used only by this compiler and included under the
__IBMCPP__ macro. This change cleans this up by deleting these headers.

Reviewed By: hubert.reinterpretcast, fanbo-meng

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

We already link libunwind explicitly so avoid trying to link toolchain's
default libunwind which may be missing. This matches what we already do
for libcxx.

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

Add two options, `-fprofile-function-groups=N` and `-fprofile-selected-function-group=i` used to partition functions into `N` groups and only instrument the functions in group `i`. Similar options were added to xray in https://reviews.llvm.org/D87953 and the goal is the same; to reduce instrumented size overhead by spreading the overhead across multiple builds. Raw profiles from different groups can be added like normal using the `llvm-profdata merge` command.

Reviewed By: ianlevesque

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

Follow up fix to
commit 2240d72f ("[X86] initial -mfunction-return=thunk-extern
support")
https://reviews.llvm.org/D129572

@nathanchance reported that -mfunction-return=thunk-extern was failing
to annotate the asan and tsan contructors.
https://lore.kernel.org/llvm/Ys7pLq+tQk5xEa%2FB@dev-arch.thelio-3990X/

I then noticed the same occurring for gcov synthetic functions.

Similar to
commit 2786e673 ("[IR][sanitizer] Add module flag "frame-pointer" and set
it for cc1 -mframe-pointer={non-leaf,all}")
define a new module level MetaData, "fn_ret_thunk_extern", then when set
adds the fn_ret_thunk_extern IR Fn Attr to synthetically created
Functions.

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

Reviewed By: MaskRay

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

As discussed in D128123, this test is based on an example
that ends up with codegen regressions if sub is converted
to xor.

Reviewed By: MaskRay

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

Widening a G_FCONSTANT by extending and then generating G_FPTRUNC doesn't produce
the same result all the time. Instead, we can just transform it to a G_CONSTANT
of the same bit pattern and truncate using a plain G_TRUNC instead.

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

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

Reviewed By: ldionne, #libc

Spies: arichardson, sstefan1, libcxx-commits

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

This reverts commit b7e77ff2.

Reason: Broke sanitizer builds bots + libcxx. 'static assertion
expression is not an integral constant expression'. More details
available in the Phabricator review: https://reviews.llvm.org/D129048

Follow up to 3bc09c7d - remove a fixme I forgot to remove, and add test cases showing remaining work.

Note that scaled vscales show up in vectorized code from a couple of sources:
* Element types smaller than vector block size (i.e. everything under i64)
* Unrolling
* LMUL > 1

The largest scaling we can currently have is 256 (e8 in every possible vector register).  More practically useful scales are in the 2-16 range.

Revert "[lldb] Add support for using integral const static data members in the expression evaluator"

This reverts commit 48678721.

This broke the windows lldb bot: https://lab.llvm.org/buildbot/#/builders/83/builds/21186

Nobody knows if there are users of libc++ with MSVC. Let's try to find that out and encourage them to upstream their changes to make that configuration work.

Reviewed By: ldionne, #libc

Spies: libcxx-commits

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

Remove m_inferior_prev_state that's not suitable for multiprocess
debugging and that does not seem to be really used at all.

The only use of the variable right now is to "prevent" sending the stop
reason after attach/launch.  However, this code is never actually run
since none of the process plugins actually use eStateLaunching or
eStateAttaching.  Through adding an assert, I've confirmed that it's
never hit in any of the LLDB tests or while attaching/launching debugged
process via lldb-server and via lldb CLI.

Differential Revision: https://reviews.llvm.org/D128878
Sponsored by: The FreeBSD Foundation