The underlying clang bug seems to have been fixed in and test is
consistently passing on aarch64-linux buildbot.

I originally reverted the patch because it was causing performance
issues, but now I think it's just enabling simplify-cfg to do
something that I don't want instead :)

Sorry for the noise.

This reverts commit 3e39760f.

Subscribers: arichardson, hiraditya, thopre, llvm-commits

Tags: #llvm

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

The invoke instruction can have profile metadata with branch_weights,
which does not make sense for a call instruction and will be
rejected by the verifier.

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

Introduce an helper class to aggregate the cleanup in case of rollback.

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

This reverts commit 47650451
while I investigate the build bot failures.

Reviewers: efriedma, davide

Reviewed By: efriedma

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

This emits new IR intrinsic @llvm.get.active.mask for tail-folded vectorised
loops if the intrinsic is supported by the backend, which is checked by
querying TargetTransform hook emitGetActiveLaneMask.

This intrinsic creates a mask representing active and inactive vector lanes,
which is used by the masked load/store instructions that are created for
tail-folded loops. The semantics of @llvm.get.active.mask are described here in
LangRef:

https://llvm.org/docs/LangRef.html#llvm-get-active-lane-mask-intrinsics

This intrinsic is also used to provide a hint to the backend. That is, the
second argument of the intrinsic represents the back-edge taken count of the
loop. For MVE, for example, we use that to set up tail-predication, which is a
new form of predication in MVE for vector loops that implicitely predicates the
last vector loop iteration by implicitely setting active/inactive lanes, i.e.
the tail loop is predicated. In order to set up a tail-predicated vector loop,
we need to know the number of data elements processed by the vector loop, which
corresponds the the tripcount of the scalar loop, which we can now reconstruct
using @llvm.get.active.mask.

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

Refactor TTI hook emitGetActiveLaneMask and remove the unused arguments
as suggested in D79100.

Improvement of the following revision:
bbc629eb

This might still be problematic if freq = 0, so it's better to check for
that.

llvm::getHeatColor becomes a problem when maxFreq = 0 -> freq = 0 =>
log2(double(freq)) / log2(maxFreq) -> log2(0.) / log2(0.) which
results in illegal instruction on some architectures.

Problematic revision: https://reviews.llvm.org/D77172

Reviewers: david-arm, efriedma, c-rhodes

Reviewed By: c-rhodes

Tags: #clang

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

Currently load instructions are added to the cache for invariant pointer
group dependencies, but only pointer values are removed currently. That
leads to dangling AssertingVHs in the test case below, where we delete a
load from an invariant pointer group. We should also remove the entries
from the cache.

Fixes PR46054.

Reviewers: efriedma, hfinkel, asbirlea

Reviewed By: efriedma

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

This is a natural extension of the previous changes to use the Cursor
class independently in the standard and extended opcode paths, and in
turn allows delaying error handling until the entire line has been
printed in verbose mode, removing interleaved output in some cases.

Reviewed by: MaskRay, JDevlieghere

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

Summary: Depends on D81831.

Reviewers: eugenis, pcc

Reviewed By: eugenis

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

Summary:
This code is going to be used in StackSafety.
This patch is file move with minimal changes. Identifiers
will be fixed in the followup patch.

Reviewers: eugenis, pcc

Reviewed By: eugenis

Subscribers: mgorny, hiraditya, llvm-commits

Tags: #llvm

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

Check that the MemoryVT of LoadA matches that of LoadB.

This fixes https://bugs.llvm.org/show_bug.cgi?id=46239.

Review: Ulrich Weigand

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

Reviewed By: jdoerfert

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

Summary:

In the patch D62907 the PPC CTRLoops pass has been replaced by Generic
Hardware Loop pass, and it has imported some new intrinsic for Generic
Hardware Loop.

The old intrinsic used in PPC CTRLoops int_ppc_mtctr and
int_ppc_is_decremented_ctr_nonzero is been replaced by
int_set_loop_iterations and loop_decrement.

This patch is to remove above unused two instrinsic.

Reviewed By: shchenz

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

We weren't re-entering template scopes in the right order, causing this
to break self-host with -fdelayed-template-parsing.

This reverts commit 237c2a23.

The functions sys::ExcecuteAndWait and sys::Wait now have additional
argument of type pointer to structure, which is filled with process
execution statistics upon process termination. These are total and user
execution times and peak memory consumption. By default this argument is
nullptr so existing users of these function must not change behavior.

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

This matches GCC, which enabled -mms-bitfields by default for
mingw targets in 4.7 [1].

[1] https://www.gnu.org/software/gcc/gcc-4.7/changes.html

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

This diagnostic (which defaults to an error, added in
95833f33) was intended to clearly
point out cases where the C++ ABI won't match the Microsoft C++ ABI,
for cases when this is enabled via a pragma over a region of code.

The MSVC compatible struct layout feature can also be enabled via a
compiler option (-mms-bitfields). If enabled that way, one essentially
can't compile any C++ code unless also building with
-Wno-incompatible-ms-struct (which GCC doesn't support, and projects
developed with GCC aren't setting).

For the MinGW target, it's expected that the C++ ABI won't match
the MSVC one, if this option is used for getting the struct
layout to match MSVC.

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

The msvcrt library isn't a pure import library; it does contain
regular object files with wrappers/fallbacks, and these can require
linking against kernel32.

This only makes a difference when linking with ld.bfd, as lld
always searches all static libraries.

This matches a similar change made recently in gcc in
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=850533ab160ef40eccfd039e1e3b138cf26e76b8,
although clang adds --start-group --end-group around these libraries
if -static is specified, which gcc doesn't. But try to match gcc's
linking order in any case, for consistency.

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

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

Values that are uniform within a loop but appear divergent to uses
outside the loop are "tainted" so that such uses are marked
divergent. But if such a use is a branch, then it's divergence needs
to be propagated. The simplest way to do that is to put the branch
back in the main worklist so that it is processed appropriately.

Reviewed By: simoll

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

Summary:
Previously, GlobalAlias::copyAttributesFrom did not preserve ThreadLocalMode,
causing incorrect IR generation in IR linking flows. This patch pushes the code
responsible for copying this attribute from GlobalVariable::copyAttributesFrom
down to GlobalValue::copyAttributesFrom so that it is shared by GlobalAlias.
Fixes PR46297.

Reviewers: tejohnson, pcc, hans

Reviewed By: tejohnson, hans

Subscribers: hiraditya, ibookstein, dexonsmith, llvm-commits

Tags: #llvm

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

This was hidden by the IR expansion in AMDGPUCodeGenPrepare, which I
forgot to turn off.

C++ unqualified name lookup searches template parameter scopes
immediately after finishing searching the entity the parameters belong
to. (Eg, for a class template, you search the template parameter scope
after looking in that class template and its base classes and before
looking in the scope containing the class template.) This is complicated
by the fact that scope lookup within a template parameter scope looks in
a different sequence of places prior to reaching the end of the
declarator-id in the template declaration.

We used to approximate the proper lookup rule with a hack in the scope /
decl context walk inside name lookup. Now we instead compute the lookup
parent for each template parameter scope. This gets the right answer and
as a bonus is substantially simpler and more uniform.

In order to get this right, we now make sure to enter a distinct Scope
for each template parameter scope. (The fact that we didn't before was
already a bug, but not really observable most of the time, since
template parameters can't shadow each other.)

redeclaration chain for an array.

A prior attempt to fix this in r280330 didn't handle the case where the
old variable is dependent and the new one is not.

It is notable and worrying that the test case in this example forms a
redeclaration chain for a non-dependent variable that includes a
declaration with a dependent type. We should probably fix that too.

remove the wrong added comments as xsmaddasp is introduced in PWR8

Summary:
So things work on 32-bit machines. (@vzakhari reported the
breakage starting from D80177).

Reviewers: #lld-macho, vzakhari

Subscribers: llvm-commits, vzakhari

Tags: #llvm

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