Changes

Remove superfluous whitespace around if(). NFC.

[SLP] Add AArch64 tests with vectorizable compare/select patterns.

This patch adds an additional set of tests that can be vectorized
efficiently on AArch64, using CMxx & BFI.

Correct LIT test failure detected on buildbot after mibintc committed rG2e204e23911b: [clang] Enable support for #pragma STDC FENV_ACCESS D87528

[InstSimplify] add tests for logic-of-cmps with not op; NFC

One variant of this is shown in:
https://llvm.org/PR47858

[InstSimplify] peek through 'not' operand in logic-of-icmps fold

This extends D78430 to solve cases like:
https://llvm.org/PR47858

There are still missed opportunities shown in the tests,
and as noted in the earlier patches, we have related
functionality in InstCombine, so we may want to extend
other folds in a similar way.

A semi-random sampling of test diff proofs in this patch:
https://rise4fun.com/Alive/sS4C

[IndVars] Regenerate test checks (NFC)

Also run the test case through -instnamer.

[SCEV] Strength nowrap flags after constant folding

We should first try to constant fold the add expression and only
strengthen nowrap flags afterwards. This allows us to determine
stronger flags if e.g. only two operands are left after constant
folding (and thus "guaranteed no wrap region" code applies) or the
resulting operands are non-negative and thus nsw->nuw strengthening
applies.

[SCEV] Separate out constant folding in mul expr creation

Separate out the code handling constant folding into a separate
block, that is independent of other folds that need a constant
first operand. Also make some minor adjustments to make the
constant folding look nearly identical to the same code in
getAddExpr().

The only reason this change is not strictly NFC is that the
C1*(C2+V) fold is moved below the constant folding, which means
that it now also applies to C1*C2*(C3+V), as it should.

[SCEV] Always constant fold mul expression operands

Establish parity with the handling of add expressions, by always
constant folding mul expression operands before checking the depth
limit (this is a non-recursive simplification). The code was already
unconditionally constant folding the case where all operands were
constants, but was not folding multiple constant operands together
if there were also non-constant operands.

This requires picking out a different demonstration for depth-based
folding differences in the limit-depth.ll test.

Thread safety analysis: Consider global variables in scope

Instead of just mutex members we also consider mutex globals.
Unsurprisingly they are always in scope. Now the paper [1] says that

> The scope of a class member is assumed to be its enclosing class,
> while the scope of a global variable is the translation unit in
> which it is defined.

But I don't think we should limit this to TUs where a definition is
available - a declaration is enough to acquire the mutex, and if a mutex
is really limited in scope to a translation unit, it should probably be
only declared there.

The previous attempt in 9dcc82f34ea was causing false positives because
I wrongly assumed that LiteralPtrs were always globals, which they are
not. This should be fixed now.

[1] https://static.googleusercontent.com/media/research.google.com/en/us/pubs/archive/42958.pdf

Fixes PR46354.

Reviewed By: aaron.ballman

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

Thread safety analysis: Nullability improvements in TIL, NFCI

The constructor of Project asserts that the contained ValueDecl is not
null, use that in the ThreadSafetyAnalyzer. In the case of LiteralPtr
it's the other way around.

Also dyn_cast<> is sufficient if we know something isn't null.

[SCEV] Strenthen nowrap flags after constant folding for mul exprs

Same change as 0dda6333175c1749f12be660456ecedade3bcf21, but for
mul expressions. We want to first fold any constant operans and
then strengthen the nowrap flags, as we can compute more precise
flags at that point.

[CostModel] fix operand/type accounting for fadd/fmul reductions

I'm not sure if/how this ever worked, but it must not be tested
currently because the basic tests added here were crashing as
noted in the post-review comments for 1c83716 (which reverted
another cost-model fix in 22d10b8ab44f).

[CostModel] remove cost-kind predicate for some vector reduction costs

This is a modified 2nd try of 22d10b8ab44f
(reverted by 1c8371692d because it managed
to expose an existing crashing bug that should be fixed by
74ffc823 ).

Original commit message:

This is similar in spirit to 01ea93d85d6e (memcpy) except that
here the underlying caller assumptions were created for vectorizer
use (throughput) rather than other passes.

That meant targets could have an enormous throughput cost with no
corresponding size, latency, or blended cost increase.
The ARM costs show a small difference between throughput and
size because there's an underlying difference in cmp/sel
costs that is also predicated on cost-kind.

Paraphrasing from the previous commits:
This may not make sense for some callers, but at least now the
costs will be consistently wrong instead of mysteriously wrong.

Targets should provide better overrides if the current modeling
is not accurate.

[X86] Use TargetConstant instead of Constant for operands to X86vaarg64.

[X86] Use TargetConstant for immediates for VASTART_SAVE_XMM_REGS.

[X86] VEX/EVEX prefix doesn't work for inline assembly.

For now, we lost the encoding information if we using inline assembly.
The encoding for the inline assembly will keep default even if we add
the vex/evex prefix.

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