Remove `TYPE BIN` parameter that is introduced in CMake 3.14 and revert back to
the equivalent compatible form `DESTINATION ${CMAKE_INSTALL_BINDIR}`.

Addresses https://github.com/llvm/llvm-project/issues/54099

Reviewed By: rafauler

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

(cherry picked from commit 018ad03e)

So far, we sort all discardable sections at the end, with only some
extra logic to make sure that the .reloc section is at the start
of that group of sections. But if there are other discardable
sections, other than .reloc, they must also be ordered before
.debug_* sections, to avoid leaving gaps if the executable is
stripped.

(Stripping executables doesn't remove all discardable sections,
only the ones named .debug_*).

Rust binaries seem to include a .rmeta section, which is marked
discardable. This fixes stripping such binaries if built with
dwarf debug info included.

This fixes issues observed in MSYS2 in
https://github.com/msys2/MINGW-packages/pull/10555.

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

(cherry picked from commit 4c3b74b7)

For the object file writer we need to allow the underflow (ar write
zero), but for the final linker output we should probably generate an
error (I've left that as a TODO for now).

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

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

(cherry picked from commit 4c75521c)

Also increase coverage of call_indirect via explict function table
(enabled when reference types is enabled) in
llvm/test/CodeGen/WebAssembly/call-indirect.ll (I believe this
was an oversight that it was not added in https://reviews.llvm.org/D90948)

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

(cherry picked from commit db7b1af8)

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

I've split the git archive generation into three steps:

1. generate pure tarball
2. append top-level cmake directory to all tarballs
3. compress the archive

This was inspired by D118252 and can be considered an alternative
approach for all projects to have access to the shared cmake
directory when building in standalone mode.

When generating source tarballs on my local laptop it takes 9 minutes and 45 seconds WITH this patch applied. When this patch is not applied, it takes 9minutes and 38 seconds. That means, this patch introduces a slowdown of 7 seconds, which seems fair.

Reviewed By: tstellar

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

The custom state machine had a check for surplus threads that filtered
the main thread if the kernel was executed by a single warp only. We
now first check for the main thread, then for surplus threads, avoiding
to filter the former out.

Fixes #54214.

Reviewed By: jhuber6

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

(cherry picked from commit f9c2d600)

After Linux kernel commit
commit 200ed341b864 ("mips: Implement "current_stack_pointer"")
We observe the following build error when compiling the Linux kernel
targeting Mips:
fatal error: error in backend: Invalid register name global variable

Fixes: https://github.com/llvm/llvm-project/issues/54174
Link: https://github.com/ClangBuiltLinux/linux/issues/1608

Reviewed By: atanasyan

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

(cherry picked from commit e0adc3be)

Fixes the incorrect removal version of the experimental coroutine
header.

Reviewed By: #libc, ldionne

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

At least insofar as GitHub's rendering is concerned, the nested list
needs a blank line prior to its first item.

At least insofar as GitHub's rendering is concerned, the lists need a blank line prior to the first item.

Reviewed By: jsji, #libc, ldionne

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

Until Zfinx is supported in CodeGen we need to convert all Zfinx
register classes to GPR.

Remove the zfinx-types.ll test which didn't test anything meaningful
since -mattr=zfinx isn't implemented completely in llc.

Follow up to D93298.

(cherry picked from commit 6cb42cd6)

Otherwise, the driver will insert e.g. -lgcc_s when
CLANG_DEFAULT_UNWINDLIB=libgcc is set during the clang build.

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

(cherry picked from commit 12d36792)

We were incorrectly using the OptimizeLayer and bypassing the COD layer.

(cherry picked from commit 1e16272b)

Without this, EPCIndirectionUtils::getResolverBlockAddr (and lazy compilation
via EPC) won't work.

No test case: lli is still using LocalLazyCallThroughManager. I'll revisit this
soon when I look at adding lazy compilation support to the ORC runtime.

(cherry picked from commit 34e539dc)

When we use liveness for edges during the `genericValueTraversal` we
need to make sure to use the AAIsDead of the correct function. This
patch adds the proper logic and some simple caching scheme. We also
add an assertion to the `isEdgeDead` call to make sure future misuse
is detected earlier.

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

Patch is from craig.topper's comments in https://reviews.llvm.org/D93298

LLVM tools do not emit `DT_MIPS_XHASH` dynamic table tag. But now
`llvm-objdump` and `llvm-readelf` recognize this tag and print it.

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

(cherry picked from commit 3c840e3c)

This reverts commit 19149538.

This fix was accidentally committed.

In BPF backend, BTF type generation may skip
some debuginfo types if they are the pointee
type of a struct member. For example,
  struct task_struct {
    ...
    struct mm_struct                *mm;
    ...
  };
BPF backend may generate a forward decl for
'struct mm_struct' instead of full type if
there are no other usage of 'struct mm_struct'.
The reason is to avoid bringing too much unneeded types
in BTF.

Alexei found a pruning bug where we may miss
some full type generation. The following is an illustrating
example:
   struct t1 { ... }
   struct t2 { struct t1 *p; };
   struct t2 g;
   void foo(struct t1 *arg) { ... }
In the above case, we will have partial debuginfo chain like below:
   struct t2 -> member p
                        \ -> ptr -> struct t1
                        /
     foo -> argument arg
During traversing
   struct t2 -> member p -> ptr -> struct t1
The corresponding BTF types are generated except 'struct t1' which
will be in FixUp stage. Later, when traversing
   foo -> argument arg -> ptr -> struct t1
The 'ptr' BTF type has been generated and currently implementation
ignores 'pointer' type hence 'struct t1' is not generated.

This patch fixed the issue not just for the above case, but for
general case with multiple derived types, e.g.,
   struct t2 -> member p
                        \ -> const -> ptr -> volatile -> struct t1
                        /
     foo -> argument arg

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

Particularly this breaks vectorization of insertelements where some of
intermediate (i.e. not last) insertelements are used externally.

Fixes PR52275
Fixes #51617

Reviewed by: ABataev

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

(cherry picked from commit b7574b09)

As reported in Issue #53690,
`tools/flang/unittests/Optimizer/FlangOptimizerTests` `FAIL`s to link on
Solaris:

  Undefined                       first referenced
   symbol                             in file
  _ZN3fir7runtimeL8getModelIcEEPFN4mlir4TypeEPNS2_11MLIRContextEEv lib/libFIRBuilder.a(Reduction.cpp.o)

which is `mlir::Type (*fir::runtime::getModel<char>())(mlir::MLIRContext*)`.

`clang++` warn's

  In file included from /var/llvm/llvm-14.0.0-rc1/rc1/llvm-project/flang/lib/Optimizer/Builder/Runtime/Reduction.cpp:14:
  /var/llvm/llvm-14.0.0-rc1/rc1/llvm-project/flang/include/flang/Optimizer/Builder/Runtime/RTBuilder.h:60:34: warning: function 'fir::runtime::getModel<char>' has internal linkage but is not defined [-Wundefined-internal]
  static constexpr TypeBuilderFunc getModel();
                                   ^
  /var/llvm/llvm-14.0.0-rc1/rc1/llvm-project/flang/include/flang/Optimizer/Builder/Runtime/RTBuilder.h:289:29: note: used here
        Ty...

When building 32b x86 code as PIC, the existing handling of "i"
constraints is conservative since generally we have to go through the
GOT to find references to functions.

But generally, BlockAddresses from C code refer to the Function in the
current TU.  Permit BlockAddresses to be used with the "i" constraint
for those cases.

I regressed this in
commit 4edb9983 ("[SelectionDAG] treat X constrained labels as i for asm")

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

Reviewed By: efriedma, MaskRay

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

(cherry picked from commit 027c16be)

These aliases are produced by MergeFunctions and need to be mangled according to the calling convention of the function they are pointing to instead of defaulting to the C calling convention.

Reviewed By: rnk

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

(cherry picked from commit 54b909de)

'streaming-sve' is not a feature that users should be able to set,
hence why it shouldn't show up in user-diagnostics. The only
flag that end-users should be able to set is '+sme'.

Reviewed By: paulwalker-arm

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

(cherry picked from commit ffa4dfc8)

`UsedAssumedInformation` is a return argument utilized to determine what
information is known. Most APIs used it already but
`genericValueTraversal` did not. This adds it to `genericValueTraversal`
and replaces `AllCallSitesKnown` of `checkForAllCallSites` with the
commonly used `UsedAssumedInformation`.

This was supposed to be a NFC commit, then the test change appeared.
Turns out, we had one user of `AllCallSitesKnown` (AANoReturn) and the
way we set `AllCallSitesKnown` was wrong as we ignored the fact some
call sites were optimistically assumed dead. Included a dedicated test
for this as well now.

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

Add an explicit LIBCXX_CXX_ABI=system-libcxxabi option for linking to
system-installed libc++abi. This fixes the ability to link against one
when building libcxx via the runtimes build, as otherwise the build
system insists on linking into in-tree targets.

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

(cherry picked from commit ba4f1e44)

Apparently modern versions of ounit2 can only be found as "ounit2"
rather than "oUnit" version 2.  Update the CMake check to support both
variants.  This makes the OCaml tests run again with ounit2-2.2.4.

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

(cherry picked from commit 919dba92)

https://reviews.llvm.org/D91906 did most of the work necessary to fix libunwind on
32-bit PowerPC processors without AltiVec, but there was one more piece necessary.

Reviewed By: luporl

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

(cherry picked from commit 3fa2e66c)

Follow-up to 458ead66, which replaced the bespoke CMakeLists.txt
file for building a custom instrumented libc++ with an invocation of the
runtimes build.

In the the bespoke CMakeLists.txt, the LIBCXX_CXX_ABI setting was forced
to libcxxabi, but this was not done for the CMake invocation for the
runtimes build. This would cause CMake configuration issues on platforms
where the default LIBCXX_CXX_ABI setting is not libcxxabi, such as
FreeBSD.

Add `-DLIBCXX_CXX_ABI=libcxxabi` to that invocation, to make sure the
custom instrumented libc++ always uses the expected ABI.

Reviewed By: phosek

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

(cherry picked from commit a9f1a9c0)

Similar to D116843 for Gnu.cpp

Reviewed By: MaskRay

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

(cherry picked from commit cbd9d136)

Similar to D116843 for Gnu.cpp

Reviewed By: MaskRay

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

(cherry picked from commit d241ce0f)

Use SetVector instead of DenseSet to ensure we always generate the same
name for the same function. This issue is found in
https://github.com/llvm/llvm-project/issues/53768.

Reviewed By: quinnp, rdzhabarov

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

(cherry picked from commit d56ef5ed)

By failing to lex the token we end up both parsing it as a binary
operator ourselves and parsing it as a unary operator when calling
parseExpression on the RHS. For plus this is harmless but for minus this
parses "foo - 4" as "foo - -4", effectively treating a top-level minus
as a plus.

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

Reviewed By: asb, MaskRay

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

(cherry picked from commit 6aa8521f)

Summary:
This patch changes the ClangLinkerWrapper to use the executable path
when searching for the lld binary. Previously we relied on the program
name. Also not finding 'llvm-strip' is not considered an error anymore
because it is an optional optimization.

(cherry picked from commit 7ee8bd60)

Add the build directory to the search path for llvm-strip instead
of solely relying on the PATH environment variable setting.

Reviewed By: jhuber6

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

(cherry picked from commit 8ea4aed5)

Blocks with UnreachableInst terminators are considered as root nodes in
the PDT. This pessimize DSE, if there are no aliasing reads from the
potentially dead store and the block with the unreachable terminator.

If any of the root nodes of the PDF has UnreachableInst as terminator,
fall back to the CFG scan, even the common dominator of all killing
blocks does not post-dominate the block with potentially dead store.

It looks like the compile-time impact for the extra scans is negligible.
https://llvm-compile-time-tracker.com/compare.php?from=779bbbf27fe631154bdfaac7a443f198d4654688&to=ac59945f1bec1c6a7d7f5590c8c69fd9c5369c53&stat=instructions

Fixes #53800.

Reviewed By: nikic

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