The previous resolve only creates the host associated varaibles for
common block members, but does not replace the original objects with
the new created ones. Fix it and also compute the sizes and offsets
for the host common block members if they are host associated.

Reviewed By: kiranchandramohan

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

The real(10) is supported on x86_64. On aarch64, the value of
selected_real_kind(16) should be 16 rather than 10 since real(10)
is not supported on x86_64. Previously, the real type support check
is not target dependent. Support it now through the target triple
information.

Reviewed By: clementval

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

[clang][auto-init] Deprecate -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang

GCC 12 has been released and contains unconditional support for
-ftrivial-auto-var-init=zero:
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-ftrivial-auto-var-init

Maintain compatibility with GCC, and remove the -enable flag for "zero"
mode. The flag is left to generate an "unused" warning, though, to not
break all the existing users. The flag will be fully removed in Clang 17.

Link: https://github.com/llvm/llvm-project/issues/44842

Reviewed By: nickdesaulniers, MaskRay, srhines, xbolva00

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

Instead of using `reverse_iterator`, share the optimization between the 4 algorithms. The key observation here that `memmove` applies to both `copy` and `move` identically, and to their `_backward` versions very similarly. All algorithms now follow the same pattern along the lines of:
```
if constexpr (can_memmove<InIter, OutIter>) {
  memmove(first, last, out);
} else {
  naive_implementation(first, last, out);
}
```
A follow-up will delete `unconstrained_reverse_iterator`.

This patch removes duplication and divergence between `std::copy`, `std::move` and `std::move_backward`. It also improves testing:
- the test for whether the optimization is used only applied to `std::copy` and, more importantly, was essentially a no-op because it would still pass if the optimization was not used;
- there were no tests to make sure the optimization is not used when the effect would be visible.

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

The current generation is unsafe as it is evaluated during verify
invocation rather than during verifySymbolUses. Remove until this is
safely generated.

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

One of the sources is the same size as the destination so that source
doesn't have an overlap with the destination register. By using the _TIED
form we avoid an early clobber contraint for that source.

This matches what was already done for instrinsics. ConvertToThreeAddress
will fix it if it can't stay tied.

Fix https://github.com/llvm/llvm-project/issues/58101

To avoid name conflict with `elf::ctx`.

SDAG does this, GISel doesn't.

See https://gcc.godbolt.org/z/sqjMx3Tfv

More context:
https://github.com/llvm/llvm-project/issues/57256

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

This removes one global variable and removes GOT and unique_ptr indirection.

Add LLVM_LIBRARY_VISIBILITY to remove unneeded GOT and unique_ptr indirection.

Reviewed By: ldionne, Mordante, #libc

Spies: libcxx-commits

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

Reviewed By: ldionne, #libc

Spies: sstefan1, libcxx-commits, jeroen.dobbelaere

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

This fixes the `urem_undef_lhs` case in the following:

https://gcc.godbolt.org/z/Wo9x7o679

Also see https://github.com/llvm/llvm-project/issues/57256 for more related
bugs.

This is equivalent to the undef bits in `simplifyDivRem` in the DAGCombiner.

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

`LLVM_DISTRIBUTION_COMPONENTS` now influences the llvm binary in the
normal cmake output directory when it is set. This allows for
distribution targets to only include tools they want in the llvm
binary. It must be done this way because only one target can be
associated with a specific output name.

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

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

Add LLVM_LIBRARY_VISIBILITY to remove unneeded GOT and unique_ptr
indirection. We can move other global variables into ctx without
indirection concern. In the long term we may consider passing Ctx
as a parameter to various functions and eliminate global state as
much as possible and then remove `Ctx::reset`.

`config` has 1000+ uses so we try to avoid changing `config->foo`. Define a
wrapper with LLVM_LIBRARY_VISIBILITY to remove unneeded GOT and unique_ptr
indirection.

My x86-64 lld executable is 11+KiB smaller.

This moves the struct, as it is now parsed by TargetInfo, so avoiding
some includes of AST in Basic.

Profiles show that `DWARFUnit::ExtractUnitDIENoDwoIfNeeded` is both high firing (tens of thousands of calls) and fast running (15 µs mean).

Timers like this are noise and load for profiling systems, and can be removed.

rdar://100326595

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

Profiles show that `SymbolFileDWARF::FindFunctions` is both high firing (many thousands of calls) and fast running (35 µs mean).

Timers like this are noise and load for profiling systems, and can be removed.

rdar://100326595

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

This ensures PreservedCFGCheckerAnalysis is always added, independent of
whether opt was built with assertions enabled or not.

This fixes a few buildbot failures for bots that don't have assertions
enabled.

Add two tests for D57317: Deduplicate addcarry node using commutativity.
https://reviews.llvm.org/D57317

At the moment, LoopAccessAnalysis is a loop analysis for the new pass
manager. The issue with that is that LAI caches SCEV expressions and
modifications in a loop may impact SCEV expressions in other loops, but
we do not have a convenient way to invalidate LAI for other loops
withing a loop pipeline.

To avoid this issue, turn it into a function analysis which returns a
manager object that keeps track of the individual LAI objects per loop.

Fixes #50940.

Fixes #51669.

Reviewed By: aeubanks

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

This adds support under AArch64 for the target("..") attributes. The
current parsing is very X86-shaped, this patch attempts to bring it line
with the GCC implementation from
https://gcc.gnu.org/onlinedocs/gcc/AArch64-Function-Attributes.html#AArch64-Function-Attributes.

The supported formats are:
- "arch=<arch>" strings, that specify the architecture features for a
  function as per the -march=arch+feature option.
- "cpu=<cpu>" strings, that specify the target-cpu and any implied
  atributes as per the -mcpu=cpu+feature option.
- "tune=<cpu>" strings, that specify the tune-cpu cpu for a function as
  per -mtune.
- "+<feature>", "+no<feature>" enables/disables the specific feature, for
  compatibility with GCC target attributes.
- "<feature>", "no-<feature>" enabled/disables the specific feature, for
  backward compatibility with previous releases.

To do this, the parsing of target attributes has been moved into
TargetInfo to give the target the opportunity to override the existing
parsing. The only non-aarch64 change should be a minor alteration to the
error message, specifying using "CPU" to describe the cpu, not
"architecture", and the DuplicateArch/Tune from ParsedTargetAttr have
been combined into a single option.

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

Change the costmodel to lower a = b * C where C = -(2^n - 2^m) to
            lsl     w8, w0, m
            sub     w0, w8, w0, lsl n
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D134934

Reviewed By: ldionne, #libc, huixie90

Spies: huixie90, libcxx-commits, mgorny

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

Combine cmp with zero and all versions of AND, ORR, EOR and BIC instructions into S-suffixed versions.

Related issue: https://github.com/llvm/llvm-project/issues/57122

Reviewed By: efriedma, samtebbs

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

VALU use of an SGPR (pair) as mask followed by SALU write to the
same SGPR can cause incorrect execution of subsequent SALU reads
of the SGPR.

Reviewed By: foad, rampitec

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

This patch allows the type of DenseElementsAttr to be any shaped type.

Reviewed By: rriddle

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