This reverts commit f9ff4988.
Accidentally landed a draft patch.

This patch provides initial support of building Clang runtimes for
Windows when using Fuchsia Clang toolchains under Linux.

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

WIP

There is a failure where we somehow get an invalid register
number being used to calculate the canonical frame address,
and this ends up with lldb crashing with a null deref because it
assumes that it is always able to find information about that
register.

This patch adds a check for a failure to get a register, and
declares the frame invalid in that case, with some additional
logging or an assert for debug builds.

Differential Revision: https://reviews.llvm.org/D143232
rdar://104428038

This reverts commit 254e2ad8.
It contains broken test.

VarArgSystemZHelper.visitCallBase() checks whether the callee has the
"use-soft-float" attribute, but if the callee is a function pointer, a
null pointer dereference happens.

Fix by checking this attribute on the current function. Alternatively,
one could try the callee first, but this is pointless, since one should
not be mixing hardfloat and softfloat code anyway.

Reviewed By: uweigand

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

Widen element types of vector arguments of G_ADD, G_SUB, G_MUL, G_AND,
G_OR, G_XOR to the minumum supported size, in order to support vectors
of narrow types.

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

[llvm-profdata] Fix bug llvm-profdata crashes when reading a text sample profile with an empty line with spaces.

Text editors can introduce spaces aligning the previous line's indentation. This crashes llvm-profdata. Added check to handle this case.

Reviewed By: snehasish

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

If a struct/enum type used in a record doesn't have a forward decl /
def, an implicit one is injected into the struct. This stops clang from
randomizing the structure in some situations---i.e. when the struct
contains only function pointers. So we accept forward decls so they
don't prevent randomization.

Fixes 60349

Reviewed By: MaskRay, nickdesaulniers

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

Rationale:
Only proper vectors and scalars of floating-point or integral types
are actually lowered to calls into the light-weight output library.

Reviewed By: ThomasRaoux

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

This adds the hint to a number of tensor allocations in codegens,
shaving off quite some time from e.g. reading in sparse matrices
due to zero-reallocation scheme. Note that we can probably provide
hints on all allocations, and refine the heuristics that use them
for general tensors.

Reviewed By: bixia

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

There's an early-exit case for regalloc when we don't even get a chance
to ask for an advisor (priority or eviction), and switch the context.
Then, when we want to log the reward for that function (==the one with
the early exit case), we hit the error case where the function's name
doesn't match the last-seen context.

There are a few possible fixes, one would be to just switch context when
output-ing the reward, which would be correct. This patch opts for the
alternative where we check any loging happened in the first place - just
to re-validate that no function would have been regaloc-ed without first
log-ing its reward.

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

These are part of the optimization pipeline, of which the legacy pass manager version is deprecated.

remove -no-opaque-pointers

Reviewed by: Matt Arsenault

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

It's part of the optimization pipeline, which the legacy pass manager version is deprecated.

As mentioned on https://discourse.llvm.org/t/issues-in-llvm-tblgen-high-parallelized-build/68037, ItaniumManglingCanonicalizer is often slow to build, resulting in a bottleneck for distributed builds while waiting for LLVMSupport to complete.

SymbolRemappingReader is the only current user of ItaniumManglingCanonicalizer, and this is only used by ProfileData and llvm-cxxmap - so I propose we move both files into the ProfileData library.

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

Driver::getToolChain called by Driver::BuildCompilation gets the
`Triple` argument from a temporary. With delayed detection due to
LazyDetector, we would reference a dangling `Triple`.

Several cases where missing.

1. `(icmp eq/ne X*Z, Y*Z) [if Z % 2 != 0] -> (icmp eq/ne X, Y)`
    EQ: https://alive2.llvm.org/ce/z/6_HPZ5
    NE: https://alive2.llvm.org/ce/z/c34qSU

    There was previously an implementation of this that work of `Y`
    was non-constant, but it was missing if `Y*Z` evaluated to a
    constant and/or `nsw`/`nuw` where both false. As well it only
    worked if `Z` was a constant but we can check 1s bit of
    `KnownBits` to cover more cases.

2. `(icmp eq/ne X*Z, Y*Z) [if Z != 0 and nsw(X*Y) and nsw(Y*Z)] -> (icmp eq/ne X, Y)`
    EQ: https://alive2.llvm.org/ce/z/6SdAG6
    NE: https://alive2.llvm.org/ce/z/fjsq_b

    This was previously implemented only to work if `Z` was constant,
    but we can use `isKnownNonZero` to cover more cases.

3. `(icmp uPred X*Y, Y*Z) [if Z != 0 and nuw(X*Y) and nuw(X*Y)] -> (icmp uPred X, Y)`
    EQ:  https://alive2.llvm.org/ce/z/FqWQLX
    NE:  https://alive2.llvm.org/ce/z/2gHrd2
    ULT: https://alive2.llvm.org/ce/z/MUAWgZ
    ULE: https://alive2.llvm.org/ce/z/szQQ2L
    UGT: https://alive2.llvm.org/ce/z/McVUdu
    UGE: https://alive2.llvm.org/ce/z/95uyC8

    This was previously implemented only for `eq/ne` cases. As well
    only if `Z` was constant, but again we can use `isKnownNonZero` to
    cover more cases.

Reviewed By: spatel

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

We previously only did this if the `mul` was `nuw`, but it works for
any odd value.

Alive2 Links:
EQ: https://alive2.llvm.org/ce/z/6_HPZ5
NE: https://alive2.llvm.org/ce/z/c34qSU

Reviewed By: spatel

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

Reviewed By: spatel

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

Improve and enable folding of conditional branches with tail calls.

1. Make it so that conditional tail calls can be emitted even when
   there are multiple predecessors.

2. Don't guard the transformation behind -Os. The rationale for
   guarding it was static-prediction can be affected by whether the
   branch is forward of backward. This is no longer true for almost any
   X86 cpus (anything newer than `SnB`) so is no longer a meaningful
   concern.

Reviewed By: pengfei

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

If the add/sub is not single use, it will need to be materialized
later, in which case using the BMI instruction is a de-optimization in
terms of code-size and throughput.

i.e:
```
// Good
leal -1(%rdi), %eax
andl %eax, %eax
xorl %eax, %esi
...
```
```
// Unecessary BMI (lower throughput, larger code size)
leal -1(%rdi), %eax
blsr %edi, %eax
xorl %eax, %esi
...
```

Note, this may cause more `mov` instructions to be emitted sometimes
because BMI instructions only have 1 src and write-only to dst.  A
better approach may be to only avoid BMI for (and/xor X, (add/sub
0/-1, X)) if this is the last use of X but NOT the last use of
(add/sub 0/-1, X).

Reviewed By: RKSimon

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

(a & (-b)) & b is often lowered as:
    %sub  = sub i32     0, %b
    %and0 = and i32  %sub, %a
    %and1 = and i32 %and0, %b

Which won't get detected by the BLSI pattern as b & -b are never in
the same SDNode.

This patch will do a small search through associative operators and try
and place BMI patterns in the same node so they will hit the pattern.

Reviewed By: pengfei

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

Was previously de-optimizating if -march supported lzcnt as there is
no reason to add the extra instruction.

Reviewed By: RKSimon

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

The runtime function expects a 2 x newRank array and the code
was passing a newRank x 2 array. This patch updates the
creation of the array to fit the runtime expectation.

Reviewed By: jeanPerier

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

Currently when clang deals with a call to a builtin function that
is supplied with an argument that has an explicit address space
it rewrites the signature of the callee to make the types of
the formal parameters match those of the actual arguments.
This functionality was added to support OpenCL, and was
introduced with commit b919c7d9.

However, this does not work properly for "size" related address
spaces such as those used for __ptr32. This affects platforms
like Microsoft and z/OS.

This change preserves the OpenCL functionality, but will use
the formal parameter types when an address space is size-related.

Reviewed By: akhuang

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

This patch adds llvm-mt and llvm-rc to the Clang bootstrap
dependency when building the Clang under Windows.

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

breaks amdgpu buildbot

This reverts commit 402981ee.

This patch simplified the BOOTSTRAP_ flags, allowing them to be
pass through from regular flags.

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

Summary:
The wrapper bitcode currently only gets a temp file for the compiled
object. This makes it more difficult to see what was actually generated.

This reverts commit 525ed98b.

Some buildbots are failing when linking bugpoint.
Reverting to investigate that further.

There are some helpers in the Lint analysis pass that will setup
a pass manager and then run the Lint pass on a given Function/Module.

Those have been using the LegacyPassManager, but as a small step
towards removing the deprecated legacy pass manager this patch is
changing those helpers into using the new pass manager instead.

No idea if anyone is really is using those helpers. Maybe an
alternative had been to just remove them. There is at least no unit
tests or similar that verifies that they work, so I validated this
patch by using a hacked opt binary that called those functions
before running the normal pipeline.

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

This patch is updating TailDuplicator::duplicateInstruction to fix
some old bugs that has been found with an out-of-tree target. There
are three different things being addressed:

1) In one situation two subregister indices are combined using the
   composeSubRegIndices helper. But the order in which those indices
   are combined has been incorrect. For this problem I managed to
   create some kind of reproducer using AArch64 (see the test case
   touched in this patch).

2) Another fault was found in the else branch for the above situation.
   Here we do not compose the two subregisters, instead we insert a
   COPY to replace the PHI, and then the subreg index in the using
   MO remains. Thus, the virtual register created for the COPY should
   always match with the size of the original register. Therefore the
   optimization that "constrain" (or rather relax) the register
   class by looking at the instruction desc must be limited to the
   situation when there is no subregister access. Otherwise we create
   a vreg with the wrong class.

3) Last problem addressed in this patch is that when a new register
   class is picked by looking at the instruction desc, then it
   isn't guaranteed that the isAllocatable property is set for that
   class. So one need to use the getAllocatableClass helper to find
   a subclass that is allocatable before using createVirualRegister,
   or alternatively (as in this patch) just use the OrigRC instead
   of relaxing the register class for the COPY destination.

Haven't been able to find any in-tree reproducers for problem 2 and 3.
The tricky part is to find a target that has register hierarchies that
match with the problem to trigger those code paths (and with subreg
accesses involved).

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

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

Originally, the following commit removed mapping coverage regions for system headers:
https://github.com/llvm/llvm-project/commit/93205af066341a53733046894bd75c72c99566db

It might be viable and useful to collect coverage from system headers in some systems.
This patch adds --system-headers-coverage option (disabled by default) to enable
collecting coverage from system headers.

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

This reverts commit 695ce48c.

The compile-time regression causing the revert has been fixed. Recommit
the original patch.

Original commit message:

   The pass should help to close a functional gap when it comes to
    reasoning about related conditions in a relatively general way.

    It addresses multiple existing issues (linked below) and the need for a
    more powerful reasoning system was also discussed recently in
    https://discourse.llvm.org/t/rfc-alternative-approach-of-dealing-with-implications-from-comparisons-through-pos-analysis/65601/7

    On AArch64, the new pass performs ~2000 simplifications on
    MultiSource,SPEC2006,SPEC2017 with -O3.

    Compile-time impact:

    NewPM-O3: +0.20%
    NewPM-ReleaseThinLTO: +0.32%
    NewPM-ReleaseLTO-g: +0.28%

    https://llvm-compile-time-tracker.com/compare.php?from=f01a3a893c147c1594b9a3fbd817456b209dabbf&to=577688758ef64fb044215ec3e497ea901bb2db28&stat=instructions:u

    Fixes #49344.
    Fixes #47888.
    Fixes #48253.
    Fixes #49229.
    Fixes #58074.

    Reviewed By: asbirlea

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

In https://reviews.llvm.org/D119036 we fixed some of the infrastructure by
removing the textual keyword.

The underlying issue of PR50592 was that clang can re-export only submodules but
under some conditions we needed to re-export the standalone module std_config
via std. This patch provides a better fix to the symptom D119036 fixed.

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

This removes a condition in the detection of AVG nodes, where we needn't be
checking the LHS of an add node as any const will be canonicalized to the RHS.