[InstSimplify] Add test cases for opportunities to fold select ?, X, undef -> X when we can prove X isn't poison

Part of addressing post-commit feedback from D83360

This is an NFC cleanup for Clang, and a bugfix for the Swift
branch. In swift-lldb one target may have multiple scratch
TypeSystems, so it is important to pick the one that belongs to the
current frame, rather than the one for the current target.

<rdar://problem/65001402>

The ConvertVectorToLLVM pass defines options that can be passed
on the command line (currently only reassociation of FP reductions
through -convert-vector-to-llvm='reassociate-fp-reductions). This
CL enables setting these options programmatically (forward looking
to more options than just reassociation, as well as setting the
values from code rather than command line).

Reviewed By: nicolasvasilache

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

This also allows intercepting these getprotoent functions on Linux as
well, since Linux exposes them.

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

be dependent if it names the right type.

This matches the GCC behavior, but no longer matches the standard
wording. However, the standard wording in this case is not in line with
the intent, which was to require the enclosing class type to be named
directly. I've reported this wording oversight to the committee.

Updated the AArch64 tests the best I could with my vague, inferred
understanding of AArch64 register banks. As far as I can tell, there
is only one 32-bit/64-bit type which will use the gpr register bank,
so we have to use the fpr bank for the other operand.

The script always fails otherwise, since we run with 'set -u'

 git blame shows these were last touched in 2004?
 Obsoleted in r13844.

Reviewed By: hans

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

Array returned by LambdaExpr::capture_inits() can contain nullptrs.

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

This reverts commit 695b33a5 beacuse
it broke the macOS bot.

deduction.

Template argument deduction can trigger substitution, both with
explicitly-specified template arguments and with deduced template
arguments in various ways. We previously had no check for stack
exhaustion along some of those codepaths, making it fairly easy to crash
clang with a template resulting in a substitution that referred back to
that same template. We should now produce a proper diagnostic for such
cases rather than crashing.

As noted here https://lists.llvm.org/pipermail/llvm-dev/2016-October/106182.html and by alive2, this transform isn't valid. If X is poison this potentially propagates poison when it shouldn't.

This same transform still exists in DAGCombiner.

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

This reverts commit 0369dc98.

Many failing tests.

When simplifying comparisons using a dominating assume, bail out
if the context instruction is not inserted.

Move operand type restriction to the end of the description. This
hopefully makes the intention more clear.

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

Reviewers: ro

Subscribers: llvm-commits

Tags: #llvm

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

VerifySDNode(...) in SelectionDAG.cpp shows that the operands of a BUILD_VECTOR must all be the same type. This patch cleans up the comment in ISDOpcodes.h to make that more obvious. Also, remove the requirement that the number of elements must be a power-of-2. That's not true.

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

The `noundef` attribute indicates an argument or return value which
may never have an undef value representation.

This patch allows LLVM to parse the attribute.

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

LLVM currently does not require function parameters or return values
to be fully initialized, and does not care if they are poison. This can
be useful if the frontend ABI makes no such demands, but may prevent
helpful backend transformations in case they do. Specifically, the C
and C++ languages require all scalar function operands to be fully
determined.

Introducing this attribute is of particular use to MemorySanitizer
today, although other transformations may benefit from it as well.
We can modify MemorySanitizer instrumentation to provide modest (17%)
space savings where `frozen` is present.

This commit only adds the attribute to the Language Reference, and
the actual implementation of the attribute will follow in a separate
commit.

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

Summary:
This patch makes the peeling properties of the loop accessible by other loop transformations.

Author: sidbav (Sidharth Baveja)

Reviewers: Whitney (Whitney Tsang), Meinersbur (Michael Kruse), skatkov (Serguei Katkov), ashlykov (Arkady Shlykov), bogner (Justin Bogner), hfinkel (Hal Finkel)

Reviewed By: Meinersbur (Michael Kruse)

Subscribers: fhahn (Florian Hahn), hiraditya (Aditya Kumar), llvm-commits, LLVM

Tag: LLVM

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

This reverts commit fead250b.

Summary:
This patch makes the peeling properties of the loop accessible by other loop transformations.

Author: sidbav (Sidharth Baveja)

Reviewers: Whitney (Whitney Tsang), Meinersbur (Michael Kruse), skatkov (Serguei Katkov), ashlykov (Arkady Shlykov), bogner (Justin Bogner), hfinkel (Hal Finkel)

Reviewed By: Meinersbur (Michael Kruse)

Subscribers: fhahn (Florian Hahn), hiraditya (Aditya Kumar), llvm-commits, LLVM

Tag: LLVM

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

The generated version of the file is already installed -- we shouldn't
install the pre-generation version of the file.

This is an LLD-specific option. We have enforced double-dash forms for
other options (reduce collision with short options) but missed this one.

GFX10 image instructions use one or more address operands starting at
vaddr0, instead of a single vaddr operand, to allow for NSA forms.

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

Use the algorithm from AMDGPUCodeGenPrepare::expandDivRem32.

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

Use the algorithm from AMDGPUCodeGenPrepare::expandDivRem32.

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

Fix the division/remainder algorithm by adding a second quotient
refinement step, which is required in some cases like
0xFFFFFFFFu / 0x11111111u (https://bugs.llvm.org/show_bug.cgi?id=46212).

Also document, rewrite and simplify it by ensuring that we always have a
lower bound on inv(y), which simplifies the UNR step and the quotient
refinement steps.

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

Reviewers: efriedma, fhahn, reames, kmclaughlin, sdesmalen

Reviewed By: sdesmalen

Subscribers: tschuett, hiraditya, rkruppe, psnobl, dantrushin, llvm-commits

Tags: #llvm

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

It's sufficient to sniff the platform we're running on using the compiler
macros -- we don't need to run any code.

Thanks to @lewissbaker who pointed out the unnecessary condition in
https://reviews.llvm.org/D81954#inline-756872. Since this codepath does not
make use of `swap` anyway (that codepath is a different branch), we can safely
remove this condition and produce better codegen when all types are nothrow
movable but are potentially-throwing swappable.

See codegen in https://gcc.godbolt.org/z/uDFZjz

Reviewed By: ldionne, #libc

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

[X86] Enabled a bunch of 64-bit Interlocked* functions intrinsics on 32-bit Windows to match recent MSVC

This enables _InterlockedAnd64/_InterlockedOr64/_InterlockedXor64/_InterlockedDecrement64/_InterlockedIncrement64/_InterlockedExchange64/_InterlockedExchangeAdd64/_InterlockedExchangeSub64 on 32-bit Windows

The backend already knows how to expand these to a loop using cmpxchg8b on 32-bit targets.

Fixes PR46595

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

The other backends don't know what this feature is and print a
message to stderr.

I recently tried to rework some target feature stuff in X86 and
this unknown feature tripped an assert I added.

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

In the absence of TLS relaxation (rewrite of code sequences),
there is still an applicable optimization:

[gd]: General Dynamic: resolve DTPMOD to 1 and/or resolve DTPOFF statically

All the other relaxations are only performed when transiting to
executable (`!config->shared`).
Since [gd] is handled differently, we can fold `!config->shared` into canRelax
and simplify its use sites. Rename the variable to reflect to new semantics.

Reviewed By: grimar, psmith

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