[RISCV] Merge rv32 and rv64 vector fadd/fsub/fmul/fdiv sdnode tests into single tests files with 2 run lines.

The IR and CHECK lines are identical so just keep one copy.

As a fixme notes, both of these directory iterator implementations are
conceptually similar and duplicate the functionality of returning and uniquing
entries across two or more directories. This patch combines them into a single
class 'CombiningDirIterImpl'.

This also drops the 'Redirecting' prefix from RedirectingDirEntry and
RedirectingFileEntry to save horizontal space. There's no loss of clarity as
they already have to be prefixed with 'RedirectingFileSystem::' whenever
they're referenced anyway.

rdar://problem/72485443
Differential Revision: https://reviews.llvm.org/D94857

Update ElementsAttr::isValidIndex to handle ElementsAttr with a scalar. Scalar will have rank 0.

Reviewed By: rriddle

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

Legacy Fortran implementations support an alternative form of the
PARAMETER statement; it differs syntactically from the standard's
PARAMETER statement by lacking parentheses, and semantically by
using the type and shape of the initialization expression to define
the attributes of the named constant.  (GNU Fortran gets that part
wrong; Intel Fortran and nvfortran have full support.)

This patch disables the old style PARAMETER statement by default, as
it is syntactically ambiguous with conforming assignment statements;
adds a new "-falternative-parameter-statement" option to enable it;
and implements it correctly when enabled.

Fixes https://bugs.llvm.org/show_bug.cgi?id=48774, in which a user
tripped over the syntactic ambiguity.

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

v0.10 is tagged in V specification. Update the version to v0.10.

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

Not all combinations of SEW and LMUL we need to support. For example, we
only need to support [M1, M2, M4, M8] for SEW = 64. There is no need to
define pseudos for PseudoVLSE64MF8, PseudoVLSE64MF4, and PseudoVLSE64MF2.

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

A condition "mayLoadOrStore" is too broad for that function.

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

This finishes getting rid of all the avoidable Dominator Tree recalculations
in X86 optimized codegen pipeline.

This doesn't help avoid any Dominator Tree recalculations just yet,
there's one more pass to go..

The previously agreed-upon deprecation period for
VectorType::getNumElements() has passed. This patch removes this method
and completes the refactor proposed in the RFC:
https://lists.llvm.org/pipermail/llvm-dev/2020-March/139811.html

Reviewed By: david-arm, rjmccall

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

This patch emits "instr_prof_hash_mismatch" function annotation metadata if
there is a hash mismatch while applying instrumented profiles.

During the PGO optimized build using instrumented profiles, if the CFG of
the function has changed since generating the profile, a hash mismatch is
encountered. This patch emits this information as annotation metadata. We
plan to use this with Propeller which is done at the machine IR level.
Propeller is usually applied on top of PGO and a hash mismatch during
PGO could be used to detect source drift.

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

LLVMTestingSupport is not part of libLLVM, and therefore can not
be linked to via LLVM_LINK_COMPONENTS.  Instead, it needs to be
specified explicitly to ensure that it is linked explicitly
even if LLVM_LINK_LLVM_DYLIB is used.  This is consistent with handling
in clangd.

Fixes PR#48931

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

Currently, for a scf.parallel (i,j,k) after the loop collapsing to 1D is done, the
IVs would be traversed as for an scf.parallel(k,j,i).

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

There are builders that do not have python 3.6. Revert until this situation can be rectified

This reverts commit 0703b075.

Previously, CMake would find any version of Python3. However, the project
claims to require 3.6 or greater, and 3.6 features are being used.

Reviewed By: yln

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

I think every target will want to remove these in the same way. Rather than
making them all implement the same code, let's just put this in
InstructionSelect.

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

Accidentaly ommitted the portion of pushing back the option in
https://reviews.llvm.org/D94986

This patch introduces a new environment variable to force monotonic
behavior for users that absolutely need it.  This is in anticipation
of 5.0 change that uses non-monotonic behavior for dynamic scheduling
by default. Fixes for that and the actual switch are coming soon.

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

Added release note for new `deviceRTLs` and hidden helper task for LLVM
12.

Reviewed By: jdoerfert

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

... just in case some implementation annotates it `[[nodiscard]]`.

This addresses PR48930.

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

Generate outline atomics if compiling for armv8-a non-LSE AArch64 Linux
(including Android) targets to use LSE instructions, if they are available,
at runtime. Library support is checked by clang driver which doesn't enable
outline atomics if no proper libraries (libgcc >= 9.3.1 or compiler-rt) found.

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

Remove the call to setFlags in favour of creating the instruction with
the correct flags in the first place, so we don't have to explicitly
notify the observer.

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

This reverts commit fae16fc0.
Breaks building compiler-rt android runtimes with trunk clang
but older NDK, see discussion on https://reviews.llvm.org/D95166

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

There were two problems with constant arrays whose lower bound is not 1.
First, when folding the arrays, we were creating the folded array to have lower
bounds of 1 but, we were not re-adjusting their lower bounds to the
declared values.  Second, we were not calculating the extents correctly.
Both of these problems led to bogus error messages.

I fixed the first problem by adjusting the lower bounds in
NonPointerInitializationExpr() in Evaluate/check-expression.cpp.  I wrote the
class ArrayConstantBoundChanger, which is similar to the existing class
ScalarConstantExpander.  In the process of implementing and testing it, I found
a bug that I fixed in ScalarConstantExpander which caused it to infinitely
recurse on parenthesized expressions.  I also removed the unrelated class
ScalarExpansionVisitor, which was not used.

I fixed the second problem by changing the formula that calculates upper bounds
in in the function ComputeUpperBound() in Evaluate/shape.cpp.

I added tests that trigger the bogus error messages mentioned above along with
a constant folding tests that uses array operands with shapes that conform but
have different bounds.

In the process of adding tests, I discovered that tests in
Evaluate/folding09.f90 and folding16.f90 were written incorrectly, and I
fixed them.  This also revealed a bug in contant folding of the
intrinsic "lbounds" which I plan to fix in a later change.

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

If multiclass argument comes from loop varaible and argument is record type,
it will not recognize the type. This patch ensures that loop variables are
resolved correctly.

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

clang-cl already defaults to C17 for .c files, but no harm
in accepting these flags. Fixes PR48185.

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

On non-Windows platforms, --sysroot can be used to make the compiler use
a single, hermetic directory for all header and library files.

This is useful, but difficult to do on Windows. After D95472 it's
possible to achieve this with two flags:

    out/gn/bin/clang-cl win.c -fuse-ld=lld \
        /vctoolsdir path/to/VC/Tools/MSVC/14.26.28801 \
        /winsdkdir path/to/win_sdk

But that's still cumbersome: It requires two flags instead of one, and
it requires writing down the (changing) VC/Tools/MSVC version.

This adds a new `/winsysroot <dir>` flag that's effectively an alias to
these two flags. With this, building against a hermetic Windows
toolchain only needs:

    out/gn/bin/clang-cl win.c -fuse-ld=lld /winsysroot path

`/winsysroot <dir>` is the same as adding

    /vctoolsdir <dir>/VC/Tools/MSVC/<vctoolsver>
    /winsdkdir <dir>/Windows Kits/<winsdkmajorversion>

`<vctoolsver>` is taken from `/vctoolsversion` if passed, or else it's
the name of the directory in `<dir>/VC/Tools/MSVC` that's the highest
numeric tuple.

`<winsdkmajorversion>` is the major version in /winsdkversion if passed,
else it's the name of the directory in `<dir>/Windows Kits` that's the
highest number.

So `/winsysroot <path>` requires this subfolder structure:

  path/
    VC/
      Tools/
        MSVC/
          14.26.28801  (or another number)
            include/
            ...
    Windows Kits/
      10/
        Include/
          10.0.19041.0/ (or another number)
            um/
            ...
        Lib/
          10.0.19041.0/ (or another number)
            um/
              x64/
              ...
            ...

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

[X86][SSE] combineExtractWithShuffle - support zero-extending to allow extracting from narrow shuffle masks

If the shuffle mask can't be widened to match the original extracted element width, see if the upper bits are zeroable - which allows us to extract+zero-extend the smaller extraction.

The library is not actually static when BUILD_SHARED_LIBS is on, and tests need to explicitly load it already. Also, the shared objects it was linked to did not use any symbols from it and it was therefore never linked to it.

Reviewed By: ftynse

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

On second thought, this can't properly be reused for highlighting.

Consider this example, which Quality wants to consider function-scope,
but highlighting must consider class-scope:

void foo() {
  class X {
    int ^y;
  };
}

This prepares for reuse from the semantic highlighting code.

There's a bit of yak-shaving here:
 - when the enum is moved into the clangd namespace, promote it to a
   scoped enum. This means teaching the decision forest infrastructure
   to deal with scoped enums.
 - AccessibleScope isn't quite the right name: e.g. public class members
   are treated as accessible, but still have class scope. So rename to
   SymbolScope.
 - Rename some QualitySignals members to avoid name conflicts.
   (the string) SymbolScope -> Scope
   (the enum) Scope -> ScopeKind