This was an accidental behaviour change in D106789 and this patch
restores it back to original state.

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

(cherry picked from commit 73c00d40)

The isEssentiallyExtractHighSubvector function currently calls
getVectorNumElements on a type that in specific cases might be scalable.
Since this function only has correct behaviour at the moment on scalable
types anyway, the function can just return false when given a fixed type.

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

(cherry picked from commit b297531e)

In the raw profile, binary ids immediately follow the header so when
computing counters offset we need to account for the new section.

(cherry picked from commit 8111f2f7)

Add missing break statements identified by static analysis tools.

Patch by Andrii Kurdiumov!

Reviewed By: compnerd, danielkiss

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

(cherry picked from commit 08a5ac36)

Due to a typo, this replaced %x with umax(C1, umin(C2, %x + C3))
rather than umax(C1, umin(C2, %x)). This didn't make a difference
for the existing tests, because the result is only used for range
calculation, and %x will usually have an unknown starting range,
and the additional offset keeps it unknown. However, if %x already
has a known range, we may compute a result range that is too
small.

(cherry picked from commit 8d54c8a0)

The test is based on a miscompile example in:
https://llvm.org/PR51321

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

(cherry picked from commit e1e4bf17)

(cherry picked from commit 9790a2a7)

(cherry picked from commit bce178a5)

(cherry picked from commit d8cd7806)

Per the contract of ReadLateParsedTemplates, we should not be returning
the same results multiple times. No functionality change intended, other
than to runtime.

Thanks to Luboš Luňák for identifying the cause of the regression!

(cherry picked from commit 6eda66b0)

See PR51708.

Attempting copy elision in dependent contexts with invalid variable,
such as a variable with incomplete type, would cause a crash when attempting
to calculate it's alignment.

The fix is to just skip this optimization on invalid VarDecl, as otherwise this
provides no benefit to error recovery: This functionality does not try to
diagnose anything, it only calculates a flag which will affect where the
variable will be allocated during codegen.

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>

Reviewed By: rtrieu

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

(cherry picked from commit d98c34f4)

(cherry picked from commit 775ab780)

(cherry picked from commit b989662e)

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

(cherry picked from commit 466451c6)

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

In some build configurations, the target we depend on is not available for declaring the build dependency.
We only need to declare the build dependency, if the build target is available in the same build.

Fixes the issue raised in https://reviews.llvm.org/D107156#2969862
This patch should go into release/13 together with D108404

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

(cherry picked from commit 5ea1c371)

D107156 and D107320 are not sufficient when OpenMP is built as llvm runtime
(LLVM_ENABLE_RUNTIMES=openmp) because dependencies only work within the same
cmake instance.

We could limit the dependency to cases where libomptarget/plugins are really
built. But compared to the whole llvm project, building openmp runtime is
negligible and postponing the build of OpenMP runtime after the dependencies
are ready seems reasonable.

The direct dependency introduced in D107156 and D107320 is necessary for the
case where OpenMP is built as llvm project (LLVM_ENABLE_PROJECTS=openmp).

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

(cherry picked from commit 4bb36df1)

This patch fixes an issue where RISCV's `findCommutedOpIndices` would
incorrectly return the pseudo `CommuteAnyOperandIndex` as a commutable
operand index, rather than fixing a specific index.

Reviewed By: rogfer01

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

(cherry picked from commit 5b06cbac)

[libc++][NFC] Mark values in gdb pretty print comparison functions as live to prevent values being optimized out.

It appears when testing LLVM 13 on Power, we run into failures with the
`libcxx/test/libcxx/gdb/gdb_pretty_printer_test.sh.cpp` test case optimizing
values out.

Despite some the functions in the test already being marked with optnone,
adding the `MarkAsLive()` calls inside of the pretty printer comparison functions
resolves the issues of the values being optimized out.

This patch aims to address https://llvm.org/PR51675.

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

(cherry picked from commit 217c6d64)

These tests rely on running IR code with an explicit x86_64 target triple. They won't work on other architectures. (They won't work for 32-bit processes on x86_64 hosts either. We will take care of this later.)

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

(cherry picked from commit c5ab55f5)

When a nodeduplicate COMDAT group contains a weak symbol, choose
a non-weak symbol (or one of the weak ones) rather than reporting
an error. This should address issue PR51394.

With the current IR representation, a generic comdat nodeduplicate
semantics is not representable for LTO. In the linker, sections and
symbols are separate concepts. A dropped weak symbol does not force the
defining input section to be dropped as well (though it can be collected
by GC). In the IR, when a weak linkage symbol is dropped, its associate
section content is dropped as well.

For InstrProfiling, which is where ran into this issue in PR51394, the
deduplication semantic is a sufficient workaround.

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

Per https://lists.llvm.org/pipermail/llvm-dev/2021-August/152305.html.

Reviewed By: MaskRay, fhahn

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

(cherry picked from commit 2413d606)

Reference types in the return or parameter position did cause the OpenMP
declare variant overload reasoning to give up. We should allow them as
we allow any other type.

This should fix the bug reported on the mailing list:
https://lists.llvm.org/pipermail/openmp-dev/2021-August/004094.html

Reviewed By: ABataev, pdhaliwal

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

(cherry picked from commit 2930c839)

This is a followup to D96780 to add one more pass missing from the
NewPM LTO pipeline. The missing ArgPromotion run is inserted at
the same position as in the LegacyPM, resolving the already
present FIXME:
https://github.com/llvm/llvm-project/blob/16086d47c0d0cd08ffae8e69a69c88653e654d01/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp#L1096-L1098

The compile-time impact is minimal with ~0.1% geomean regression
on CTMark.

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

(cherry picked from commit b28c3b9d)

This is a bailout for pr51680.  This pass appears to assume that the alignment operand to an align tag on an assume bundle is constant.  This doesn't appear to be required anywhere, and clang happily generates non-constant alignments for cases such as this case taken from the bug report:

// clang -cc1 -triple powerpc64-- -S -O1 opal_pci-min.c
extern int a[];
long *b;
long c;
void *d(long, int *, int, long, long, long) __attribute__((__alloc_align__(6)));
void e() {
  b = d(c, a, 0, 0, 5, c);
  b[0] = 0;
}

This was exposed by a SCEV change which allowed a non-constant alignment to reach further into the pass' code.  We could generalize the pass, but for now, let's fix the crash.

(cherry picked from commit 9b45fd90)

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

Currently, it is a bit buried in the file even if this is
pretty important for distro.

Reviewed By: MaskRay

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

This patch adds static keyword to internal functions that write
binary id to restrict visibility to the file that they are declared.

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

(cherry picked from commit 6c0e6f91)

On FreeBSD, the system `<libelf.h>` already declares `struct Elf_Note`
indirectly (via `<sys/elf_common.h>`). This results in compile errors
when building the libomptarget amdgpu plugin. Avoid redeclaring `struct
Elf_Note` on FreeBSD to fix the errors.

Reviewed By: JonChesterfield

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

(cherry picked from commit 71ae2e02)

When expanding a SMULFIXSAT ISD node (usually originating from
a smul.fix.sat intrinsic) we've applied some optimizations for
the special case when the scale is zero. The idea has been that
it would be cheaper to use an SMULO instruction (if legal) to
perform the multiplication and at the same time detect any overflow.
And in case of overflow we could use some SELECT:s to replace the
result with the saturated min/max value. The only tricky part
is to know if we overflowed on the min or max value, i.e. if the
product is positive or negative. Unfortunately the implementation
has been incorrect as it has looked at the product returned by the
SMULO to determine the sign of the product. In case of overflow that
product is truncated and won't give us the correct sign bit.

This patch is adding an extra XOR of the multiplication operands,
which is used to determine the sign of the non truncated product.

This patch fixes PR51677.

Reviewed By: lebedev.ri

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

(cherry picked from commit 789f0128)

If the icmp is in a different block, then the register for the icmp
operand may not be initialized, as it nominally does not have
cross-block uses. Add a check that the icmp is in the same block
as the branch, which should be the common case.

This matches what X86 FastISel does:
https://github.com/llvm/llvm-project/blob/5b6b090cf2129228f05d7d0f504676b67f7524cf/llvm/lib/Target/X86/X86FastISel.cpp#L1648

The "not" transform that could have a similar issue is dropped
entirely, because it is currently dead: The incoming value is
a branch or select condition of type i1, but this code requires
an i32 to trigger.

Fixes https://bugs.llvm.org/show_bug.cgi?id=51651.

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

(cherry picked from commit 16086d47)

Fixes PR51626.

The M68k requires that all instruction, word and long word reads are
aligned to word boundaries. From the 68020 onwards, there is a
performance benefit from aligning long words to long word boundaries.

The M68k uses the same data layout for pointers and integers.

In line with this, this commit updates the pointer data layout to
match the layout already set for 32-bit integers: 32:16:32.

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

(cherry picked from commit 8d3f112f)

Rename the M68kOperand::Type enumeration to KindTy to avoid ambiguity
with the Kind field when referencing enumeration values e.g.
`Kind::Value`.

This works around a compilation error under GCC 5, where GCC won't
lookup enum class values if you have a similarly named field
(see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60994).

The error in question is:
`M68kAsmParser.cpp:857:8: error: 'Kind' is not a class, namespace, or enumeration`

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

(cherry picked from commit f659b6b1)

LLVM_ENABLE_NEW_PASS_MANAGER is set to ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER, so
-DLLVM_ENABLE_NEW_PASS_MANAGER=off has no effect.

Change the cache variable to LLVM_ENABLE_NEW_PASS_MANAGER instead.
A user opting out the new PM needs to switch from
-DENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=off to
-DLLVM_ENABLE_NEW_PASS_MANAGER=off.

Also give a warning that -DLLVM_ENABLE_NEW_PASS_MANAGER=off is deprecated.

Reviewed By: aeubanks, phosek

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

(cherry picked from commit a42bd1b5)

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

(cherry picked from commit a4357bc4)

This patch XFAILs the `align.pass.cpp` for PowerPC (LE).

It appears that this test will fail on Power for the `LLIArr2` and `Padding` structs within the test,
as the `assert` for `alignof(AtomicImpl) >= sizeof(AtomicImpl)` will be false. In this case, these structs
presumably should not be lock-free, so we currently XFAIL this for now.

The failure was discovered after D97913 was committed. It looks like `alignof(AtomicImpl) < sizeof(AtomicImpl)`,
even prior to this commit, but this test began running on Power after D97913, whereas we were
not running `align.pass.cpp` before.

This patch addresses https://bugs.llvm.org/show_bug.cgi?id=51548 by temporarily XFAILing the test
in order to investigate it further.

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

(cherry picked from commit f640c31e)

Previous "simplify scan_eh_tab" patch, https://reviews.llvm.org/D93190,
saves landingpad if and only if the target is not using SjLj exceptions.
However, the landingpad is used by SjLj exception handler also.  This
patch changes to set landingpad for both exception handlers.

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

(cherry picked from commit 9d2740f3)