LICM will speculatively hoist code outside of loops. This requires removing information, like alias analysis (https://github.com/llvm/llvm-project/issues/53794), range information (https://bugs.llvm.org/show_bug.cgi?id=50550), among others. Prior to https://reviews.llvm.org/D99249 , LICM would only be run after LoopRotate. Running Loop Rotate prior to LICM prevents a instruction hoist from being speculative, if it was conditionally executed by the iteration (as is commonly emitted by clang and other frontends). Adding the additional LICM pass first, however, forces all of these instructions to be considered speculative, even if they are not speculative after LoopRotate. This destroys information, resulting in performance losses for discarding this additional information.

This PR modifies LICM to accept a ``speculative'' parameter which allows LICM to be set to perform information-loss speculative hoists or not. Phase ordering is then modified to not perform the information-losing speculative hoists until after loop rotate is performed, preserving this additional information.

Reviewed By: lebedev.ri

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

(cherry picked from commit d9da6a53)

(cherry picked from commit 07cf9594)

(cherry picked from commit a5b9987a)

(cherry picked from commit 73ee8287)

This is an alternative to D120330, which disables MachineSink for
functions with irreducible cycles entirely. This avoids both the
correctness problem, and ensures we don't perform non-profitable
sinks into cycles. At the same time, it may also disable
profitable sinks in the same function. This can be made more
precise by using MachineCycleInfo in the future.

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

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

(cherry picked from commit 6fde0439)

(cherry picked from commit e075bf6b)

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
        TypeBuilderFunc ret = getModel<RT>();
                              ^

Fixed by adding an explicit template instantiation for `getModel<char>`.  I
suppose this is necessary because on Solaris `char` is `signed`.

Tested on `sparcv9-sun-solaris2.11`.

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

(cherry picked from commit c2b9e967)

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)