In the integer case, step will be negative and InductionOpCode will be
Sub for inductions counting down.

By using the InductionOpCode for integers, we would incorrectly subtract
a negative value, when it should be added instead.

This fixes #54427 on the 14.x branch.

Reduced test for #54427.

This is part of solving issue #54750 - in that example
we have both forms of the compare and do not recognize
the equivalence.

(cherry picked from commit 2c2568f3)

The issue affects targets supporting fast-lzcnt such as btver2.
This removes extraneous zext/trunc node insertions to fix the infinite
loop.
This fixes Issue https://github.com/llvm/llvm-project/issues/54694

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

Reviewed By: RKSimon, spatel, lebedev.ri

(cherry picked from commit a3d5f1cf

)
Signed-off-by: Warren Ristow <warren.ristow@sony.com>

In https://reviews.llvm.org/D122900 a new function (to exercise the
infinite-loop bug) was added to llvm/test/CodeGen/X86/lzcnt-zext-cmp.ll.
In applying the fix in the main branch, two previously existing
functions in that test also changed behavior slightly, and in the review
it was noted:
    The instructions generated end up being reordered in some cases
    but I think it is equivalent.
That reordering did not happen in those pre-existing functions when
applying the fix to the slightly older code-base of the llvm14 branch,
and so they are suppressed here.  So the updated version of the test in
this commit has the additional function added to it, but it is otherwise
identical to the previous llvm14 version of the test.

When an inline builtin declaration is shadowed by an actual declaration, we must
reference the actual declaration, even if it's not the last, following GCC
behavior.

This fixes #54715

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

(cherry picked from commit 301e0d91)

Cherry-picked from c3b98194
which was originally reviewed as https://reviews.llvm.org/D121707.

This reverts commit edb7ba71.

This changes BLR_BTI to take variable_ops meaning that we can accept
a register or a label. The pattern still expects one argument so we'll
never get more than one. Then later we can check the type of the operand
to choose BL or BLR to emit.

(this is what BLR_RVMARKER does but I missed this detail of it first time around)

Also require NoSLSBLRMitigation which I missed in the first version.

Variable locations now come in two modes, instruction referencing and
DBG_VALUE. At -O0 we pick DBG_VALUE to allow fast construction of variable
information. Unfortunately, SelectionDAG edits the optimisation level in
the presence of opt-bisect-limit, meaning different passes have different
views of what variable location mode we should use. That causes assertions
when they're mixed.

This patch plumbs through a boolean in SelectionDAG from start to
instruction emission, so that we don't rely on the current optimisation
level for correctness.

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

(cherry picked from commit fb6596f1)

Otherwise, with recent versions of libstdc++, clang can't tell that the
atomic operations are properly aligned, and generates calls to
libatomic.  (Actually, because of the use of reinterpret_cast, it wasn't
guaranteed to be aligned, but I think it ended up being aligned in
practice.)

Fixes https://github.com/llvm/llvm-project/issues/54790 , the part where
LLVM failed to build.

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

(cherry picked from commit 13fc1781)

dd917342 (Add clear_cache implementation for ppc64. Fix buffer to
meet ppc64 alignment., 2017-07-28), adds an implementation for
__builtin___clear_cache on powerpc64, which was promptly ammended to
also be used with big endian mode in f67036b6 (This ppc64 implementation
of clear_cache works for both big and little endian., 2017-08-02)

clang will use this implementation for it's builtin on FreeBSD and result
in an abort() in the cases where 32-bit generation was requested (ex in
macppc or when the big endian powerpc64 build was done with "-m32") and as
reported[1] recently with pcre2, but there is no reason why the same code
couldn't be used in those cases, so use instead the more generic identifier
for the PowerPC architecture.

While at it, update the comment to reflect that POWER8/9 have a 128 byte
wide cache line and so the code could instead use 64 byte windows instead
but that possible optimization has been punted for now.

[1] https://github.com/PhilipHazel/pcre2/issues/92

Reviewed By: jhibbits, #powerpc, MaskRay

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

(cherry picked from commit 81f5c627)

The Linux kernel build uses absolute expressions suffixed with @lo/@ha
relocations. This currently doesn't work for DS/DQ form instructions and
there is no reason for it not to. It also works with GAS.
This patch allows this as long as the value is a multiple of 4/16
for DS/DQ form.

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

(cherry picked from commit 2aaba44b)

* fixed remote test script arguments for libc++/compiler-rt libraries.
* disabled shared libc++abi libraries (to let remote tests get passed).

(cherry picked from commit 41f74bc7)

[CMake] Replace `TARGET_TRIPLE` with `TOOLCHAIN_TARGET_TRIPLE` for Win-to-Arm cross toolchain cache file. NFC.

Avoid using TARGET_TRIPLE argument for the cross toolchain cmake cache file and replace it
with TOOLCHAIN_TARGET_TRIPLE.

Reference: https://reviews.llvm.org/D119918

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

(cherry picked from commit d860ac5d)

Removed passing CMAKE_AR from the library configurations.

(cherry picked from commit 19c1b084)

Provide CMAKE_SYSROOT for the libc++/libc++abi/libunwind libraries
instead of specific <foo>_SYSROOT for each of them.

Fixed passing some CMake arguments for the runtimes.

Referenced Differentials:
 * https://reviews.llvm.org/D119836
 * https://reviews.llvm.org/D112155
 * https://reviews.llvm.org/D111672

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

(cherry picked from commit 18fa0b15)

Follow-up from 98bc304e - while that
commit fixed when you had two PDBs colliding on the same Guid it didn't
fix the case where you had more than two PDBs using the same Guid.

This commit fixes that and also tests much more carefully that all
the types are correct no matter the order.

Reviewed By: aganea, saudi

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

(cherry picked from commit 0dfa8a01)

Microsoft shipped a bunch of PDB files with broken/invalid GUIDs
which lead lld to use 0xFF as the key for these files in an internal
cache. When multiple files have this key it will lead to collisions
and confused symbol lookup.

Several approaches to fix this was considered. Including making the key
the path to the PDB file, but this requires some filesystem operations
in order to normalize the file path.

Since this only happens with malformatted PDB files and we haven't
seen this before they malformatted files where shipped with visual
studio we probably shouldn't optimize for this use-case.

Instead we now just don't insert files with Guid == 0xFF into the
cache map and warn if we get collisions so similar problems can be
found in the future instead of being silent.

Discussion about the root issue and the approach to this fix can be found on Github: https://github.com/llvm/llvm-project/issues/54487

Reviewed By: aganea

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

(cherry picked from commit 98bc304e)

The LOH pass iterates over instructions to build its custom register
state machine, but it uses the top-level bundle iterator.
This should be okay, because when the wrapper BUNDLE MI is built,
it aggregates the register defs/uses in its instructions into MOs.

However, that doesn't apply to regmasks, and accumulating regmasks
across multiple instructions would be messy business.
There are a couple AnalyzePhysRegInBundle (/Virt) helpers that
do look at regmasks, but those don't fit in very well here.

AArch64 has started to use a few bundle instructions, specifically
as glorified pseudos for variant call instructions, which have regmasks.
So the LOH pass ends up ignoring regmasks.

Concretely, this has been wrong for a while, but, on aarch64, the
most common bundle (rv_marker call) was always followed by the
attached call instruction, a plain BL with a regmask.  Which
was properly detected by the pass.

However, we recently started keeping the attached call in the bundle,
so the regmask is now ignored.  And the pass happily combines ADRPs, of
say, x8, across the bundle, resulting in corrupt pointers later.

(cherry picked from commit cfa4fe7c)

With one-use, we handle this via demanded-bits.
But We need to handle extra uses to improve issue #54750.

https://alive2.llvm.org/ce/z/aDYkPv
(cherry picked from commit 7783db55)

(cherry picked from commit 141892d4)

In some case, like in the added test case, we can reach
selectInterleaveCount with loops that actually have a cost of 0.

Unfortunately a loop cost of 0 is also used to communicate that the cost
has not been computed yet. To resolve the crash, bail out if the cost
remains zero after computing it.

This seems like the best option, as there are multiple code paths that
return a cost of 0 to force a computation in selectInterleaveCount.
Computing the cost at multiple places up front there would unnecessarily
complicate the logic.

Fixes #54413.

(cherry picked from commit ecb4171d)

We found LLVM generate wrong stack offset for RVV object when stack
having variable argument, that cause by we didn't count vaarg part during
calculate RVV stack objects.

Also update the stack layout diagram for including vaarg in the diagram.

Stack layout ref:
https://github.com/gcc-mirror/gcc/blob/master/gcc/config/riscv/riscv.cc#L3941

Reviewed By: rogfer01

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

Reviewed By: rogfer01, frasercrmck

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

RISCVMachineFunctionInfo has some fields like VarArgsFrameIndex and
VarArgsSaveSize are calculated at ISel lowering stage, those info are
not contained in MIR files, that cause test cases rely on those field
can't not reproduce correctly by MIR dump files.

This patch adding the MIR read/write for those fields.

Reviewed By: frasercrmck

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

The class `__dir_stream` is currently declared in two places: as a
top-level forward declaration in `directory_iterator.h`, and as a friend
declaration in class `directory_entry`, in `directory_entry.h`.

The former has a `_LIBCPP_HIDDEN` attribute, but the latter does not,
causing the Firefox build to complain about the visibility not matching
the previous declaration. This is because Firefox plays games with
pushing and popping visibility.

Work around this by making both `__dir_stream` declarations consistently
use `_LIBCPP_HIDDEN`.

Reviewed By: ldionne, philnik, #libc

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

(cherry picked from commit 7ab1ab0d)

In COFF, the immediates in IMAGE_REL_ARM64_PAGEBASE_REL21 relocations
are limited to 21 bit signed, i.e. the offset has to be less than
(1 << 20). The previous limit did intend to cover for this case, but
had missed that the 21 bit field was signed.

This fixes issue https://github.com/llvm/llvm-project/issues/54753.

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

(cherry picked from commit 8d7a17b7)

Update the hardware CRC32 logic in scudo to support using `-mcrc32`
instead of `-msse4.2`.  The CRC32 intrinsics use the former flag
in the newer compiler versions, e.g. in clang since 12fa608a.
With these versions of clang, passing `-msse4.2` is insufficient
to enable the instructions and causes build failures when `-march` does
not enable CRC32 implicitly:

    /var/tmp/portage/sys-libs/compiler-rt-sanitizers-14.0.0/work/compiler-rt/lib/scudo/scudo_crc32.cpp:20:10: error: always_inline function '_mm_crc32_u32' requires target feature 'crc32', but would be inlined into function 'computeHardwareCRC32' that is compiled without support for 'crc32'
      return CRC32_INTRINSIC(Crc, Data);
             ^
    /var/tmp/portage/sys-libs/compiler-rt-sanitizers-14.0.0/work/compiler-rt/lib/scudo/scudo_crc32.h:27:27: note: expanded from macro 'CRC32_INTRINSIC'
    #  define CRC32_INTRINSIC FIRST_32_SECOND_64(_mm_crc32_u32, _mm_crc32_u64)
                              ^
    /var/tmp/portage/sys-libs/compiler-rt-sanitizers-14.0.0/work/compiler-rt/lib/scudo/../sanitizer_common/sanitizer_platform.h:132:36: note: expanded from macro 'FIRST_32_SECOND_64'
    #  define FIRST_32_SECOND_64(a, b) (a)
                                       ^
    1 error generated.

For backwards compatibility, use `-mcrc32` when available and fall back
to `-msse4.2`.  The `<smmintrin.h>` header remains in use as it still
works and is compatible with GCC, while clang's `<crc32intrin.h>`
is not.

Use __builtin_ia32*() rather than _mm_crc32*() when using `-mcrc32`
to preserve compatibility with GCC.  _mm_crc32*() are aliases
to __builtin_ia32*() in both compilers but GCC requires `-msse4.2`
for the former, while both use `-mcrc32` for the latter.

Originally reported in https://bugs.gentoo.org/835870.

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

(cherry picked from commit fd1da784)

Reviewed By: amilendra

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

Discovered in the comments on D118748: we would like this namespace
to exist anytime Ranges exists, regardless of whether concepts syntax
is supported. Also, we'd like to fully granularize the <ranges> header,
which means not putting any loose declarations at the top level.

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

(cherry picked from commit 44cdca37)

[X86] lowerV8I16Shuffle - use explicit SmallVector<SDValue, 4> width to avoid MSVC AVX alignment bug

As discussed on Issue #54645 - building llc with /AVX can result in incorrectly aligned structs

(cherry picked from commit cb5c4a59)

This patch will allow better incremental adoption of these changes in downstream
cling and other users which want to experiment by customizing the execution
engine.

(cherry picked from commit 788e0f7f)

While checking is tail call optimization is possible, the calling
convention applied to fixed arguments is not the correct one.
This implies for DarwinPCS that all arguments of a vararg function will
go to the stack although fixed ones can go in registers.

This prevents non-virtual thunks to be tail optimized although they are
marked as musttail.

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

(cherry picked from commit 26cd2584)

This patch fixes a (seemingly very rare) crash during vector constant
folding introduced in D113300.

Normally, during legalization, if we create an illegally-typed node during
a failed attempt at constant folding it's cleaned up before being
visited, due to it having no uses.

If, however, an illegally-typed node is created during one round of
legalization and isn't cleaned up, it's possible for a second round of
legalization to create new illegally-typed nodes which add extra uses to
the old illegal nodes. This means that we can end up visiting the old
nodes before they're known to be dead, at which point we crash.

I'm not happy about this fix. Creating illegal types at all seems like a
bad idea, but we all-too-often rely on illegal constants being
successfully folded and being fixed up afterwards. However, we can't
rely on constant folding actually happening, and we don't have a
foolproof way of peering into the future.

Perhaps the correct fix is to revisit the node-iteration order during
legalization, ensuring we visit all uses of nodes before the nodes
themselves. Or alternatively we could try and clean up dead nodes
immediately after failing constant folding.

Reviewed By: RKSimon

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

(cherry picked from commit 43a91a84)

glibc sysdeps/aarch64/tst-vpcs-mod.S has something like:
```
.variant_pcs    vpcs_call
.global vpcs_call
```

This is supported by GNU as but leads to an error in MC. Use getOrCreateSymbol
to support a not-yet-registered symbol: call `registerSymbol` to ensure the
symbol exists even if there is no binding directive/label, to match GNU as.

While here, improve tests to check (1) a local symbol can get
STO_AARCH64_VARIANT_PCS (2) undefined .variant_pcs (3) an alias does not
inherit STO_AARCH64_VARIANT_PCS.

Reviewed By: efriedma

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

(cherry picked from commit cfbd5c8e)

We can not bitcast pointers across different address spaces. This was
previously fixed in D89577 but then in D93229 an enhancement was added
which peeks further through the ponter operand, opening up the
possibility that address-space violations could be introduced.

Instead of bailing as the previous fix did, simply insert an
addrspacecast cast instruction.

Reviewed By: lebedev.ri

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

(cherry picked from commit 2e44b787)

Fix a regression in aa27bab5: COMMON in an
SHT_PROGBITS output section caused llvm_unreachable failure.

(cherry picked from commit 1db59dc8)

(cherry picked from commit f7086401)

Fix #54456: `objcopy --only-keep-debug` produces a linked image with invalid
empty dynamic section. llvm-objdump -p currently reports an error which seems
excessive.

```
% llvm-readelf -l a.out
llvm-readelf: warning: 'a.out': no valid dynamic table was found
...
```

Follow the spirit of llvm-readelf -l (D64472) and report a warning instead.
This allows later files to be dumped despite warnings for an input file, and
improves objdump compatibility in that the exit code is now 0 instead of 1.

```
% llvm-objdump -p a.out  # new behavior
...
Program Header:
llvm-objdump: warning: 'a.out': invalid empty dynamic section
% objdump -p a.out
...
Dynamic Section:

```

Reviewed By: jhenderson, raj.khem

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

(cherry picked from commit 11a8fc68)

(cherry picked from commit 423af54c)