[SROA] For non-speculatable `load`s of `select`s -- split block, insert then/else blocks, form two-entry PHI node, take 2

Currently, SROA is CFG-preserving.
Not doing so does not affect any pipeline test. (???)
Internally, SROA requires Dominator Tree, and uses it solely for the final `-mem2reg` call.

By design, we can't really SROA alloca if their address escapes somehow,
but we have logic to deal with `load` of `select`/`PHI`,
where at least one of the possible addresses prevents promotion,
by speculating the `load`s and `select`ing between loaded values.

As one would expect, that requires ensuring that the speculation is actually legal.
Even ignoring complexity bailouts, that logic does not deal with everything,
e.g. `isSafeToLoadUnconditionally()` does not recurse into hands of `select`.
There can also be cases where the load is genuinely non-speculate.

So if we can't prove that the load can be speculated,
unfold the select, produce two-entry phi node, and perform predicated load.

Now, that transformation must obviously update Dominator Tree,
since we require it later on. Doing so is trivial.
Additionally, we don't want to do this for the final SROA invocation (D136806).

In the end, this ends up having negative (!) compile-time cost:
https://llvm-compile-time-tracker.com/compare.php?from=c6d7e80ec4c17a415673b1cfd25924f98ac83608&to=ddf9600365093ea50d7e278696cbfa01641c959d&stat=instructions:u

Though indeed, this only deals with `select`s, `PHI`s are still using speculation.

Should we update some more analysis?

Reviewed By: arsenm

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

This reverts commit 73961187,
and recommits 03e6d9d9
with a fixed assertion - we should check that DTU is there,
not just assert false...

**Summary**

Older versions of `make` would occasionally fail to realize
that a pre-requisite for the `a.out` target has changed. This
resulted in roughly 1 out of 10 test runs to fail. Instead of
relying on `make` to resolve this dependency simply remove the
file before rebuilding; this will give make no option but to
remake `a.out`.

**Testing**

* Confirmed that the test passes on the host for 100 runs where
  without the patch it would fail after ~10

**Details**

Adding `-d` to lldbtest's `make` invocation and running the
test without this patch sometimes yielded:
```
Removing child 0x600000308ff0 PID 19915 from chain.
    Successfully remade target file `rebuild.o'.
   Finished prerequisites of target file `a.out'.
   Prerequisite `rebuild.o' is newer than target `a.out'.
  No need to remake target `a.out'.
```

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

Revert "[SROA] For non-speculatable `load`s of `select`s -- split block, insert then/else blocks, form two-entry PHI node"

The assertion about not modifying the CFG seems to not hold,
will recommit in a bit.

https://lab.llvm.org/buildbot#builders/139/builds/32412

This reverts commit 03e6d9d9.
This reverts commit 4f90f4ad.

Reviewed By: Peiming

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

Rework  the recursive I/O error check on I/O units so that
threads again hold a lock on a unit throughout an I/O statement.
Add an API to the runtime's Lock class implementation for pthreads
to allow detection of solf-deadlock without depending on EDEADLK
or recursive mutexes.

This should fix I/O from OpenMP threads.

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

Reads template information from the AST and adds template parameters and
specialization information to the corresponding clang-doc structures.

Add a "QualName" to the Reference struct which includes the full
qualified type name. The Reference object represents a link in the
HTML/MD generators so is based on the unqualified name. But this does
not encode C-V qualifiers or template information that decorate the
name. The new QualName member encodes all of this information and also
makes it easier for the generators or downsteam YAML consumers to
generate the full name (before they had to process the "Path").

In test code that was changed, remove made-up paths to built-in types
like "int". In addition to slightnly cleaning up the code, these types
do not have paths in real execution, and generating incorrect references
to nonexistant data may complicate future changes in the generators.

Convert llvm::Optional to std::optional (YAML library requires this for
the new usage,...

Reviewed By: aartbik, wrengr

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

To make the lit test print-header-json.c passed on a file-content-hash
file system.

This reverts commit dd8d0d21.
As discussed in the planned follow-on to this patch (D138874),
this and the previous patch in this set can cause trouble for
the backend, and there's probably no quick fix. We may even
want to canonicalize in the opposite direction (towards insertelt).

[SROA] For non-speculatable `load`s of `select`s -- split block, insert then/else blocks, form two-entry PHI node

Currently, SROA is CFG-preserving.
Not doing so does not affect any pipeline test. (???)
Internally, SROA requires Dominator Tree, and uses it solely for the final `-mem2reg` call.

By design, we can't really SROA alloca if their address escapes somehow,
but we have logic to deal with `load` of `select`/`PHI`,
where at least one of the possible addresses prevents promotion,
by speculating the `load`s and `select`ing between loaded values.

As one would expect, that requires ensuring that the speculation is actually legal.
Even ignoring complexity bailouts, that logic does not deal with everything,
e.g. `isSafeToLoadUnconditionally()` does not recurse into hands of `select`.
There can also be cases where the load is genuinely non-speculate.

So if we can't prove that the load can be speculated,
unfold the select, produce two-entry phi node, and perform predicated load.

Now, that transformation must obviously update Dominator Tree,
since we require it later on. Doing so is trivial.
Additionally, we don't want to do this for the final SROA invocation (D136806).

In the end, this ends up having negative (!) compile-time cost:
https://llvm-compile-time-tracker.com/compare.php?from=c6d7e80ec4c17a415673b1cfd25924f98ac83608&to=ddf9600365093ea50d7e278696cbfa01641c959d&stat=instructions:u

Though indeed, this only deals with `select`s, `PHI`s are still using speculation.

Should we update some more analysis?

Reviewed By: arsenm

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

Similar to what we've done for HasMFence - this puts into place a pseudo-predicate for CLFLUSH instructions that separates it from HasSSE2 to make it easier to use CLFLUSH even when SSE/fpmath has been disabled - technically CLFLUSH has its own CPUID bit, so could be available on x86 cores entirely without SSE, but I don't think thats ever happened or likely to happen.

I tried `-undefined suppress` without `-flat_namespace`.
lld printed `'-undefined suppress' only valid with '-flat_namespace'`
followed by many many screenfuls of error messages about undefined
symbols, making the original diag hard to see.

This is probably the common case when using `-undefined`, so let's
just abort the link immediately when there's an invalid `-undefined`
arg.

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

Add a test to show a deficit in the current wwm/spilling code that
creates double saves and restores for v40 and v41.

This case came up in D124193.

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

These passes were lying around but weren't initialized, so they weren't
showing up in -print-after-all.

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

This reverts commit 42c2dc40.

This broke some buildbots:

 undefined reference to `llvm::createBitTrackingDCEPass()'
 undefined reference to `llvm::createAlignmentFromAssumptionsPass()'
 undefined reference to `llvm::createLoopUnrollPass(int, bool, bool, int, int, int, int, int, int)'
 undefined reference to `llvm::createLICMPass(unsigned int, unsigned int, bool)'
 undefined reference to `llvm::createWarnMissedTransformationsPass()'
 undefined reference to `llvm::createAlignmentFromAssumptionsPass()'
 undefined reference to `llvm::createCallSiteSplittingPass()'
 undefined reference to `llvm::createCFGSimplificationPass(llvm::SimplifyCFGOptions, std::function<bool (llvm::Function const&)>)'
 undefined reference to `llvm::createFloat2IntPass()'
 undefined reference to `llvm::createLowerConstantIntrinsicsPass()'
 undefined reference to `llvm::createLoopRotatePass(int, bool)'
 undefined reference to `llvm::createLoopDistributePass()'
 undefined reference to `llvm::createLoopSinkPass()'
 undefined reference to `llvm::createInstSimplifyLegacyPass()'
 undefined reference to `llvm::createDivRemPairsPass()'
 undefined reference to `llvm::createCFGSimplificationPass(llvm::SimplifyCFGOptions, std::function<bool (llvm::Function const&)>)'
 undefined reference to `llvm::SetLicmMssaOptCap'
 undefined reference to `llvm::SetLicmMssaNoAccForPromotionCap'
 undefined reference to `llvm::ForgetSCEVInLoopUnroll'

This reverts commit 877a9f9a.

It depends on the parent revision 42c2dc40
which needs to be reverted as it broke some buildbots, so reverting both.

This implements WG14 N2975 relaxing requirements for va_start
(https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2975.pdf), which
does two things:

1) Allows the declaration of a variadic function without any named
arguments. e.g., void f(...) is now valid, as in C++.
2) Modified the signature of the va_start macro to be a variadic macro
that accepts one or more arguments; the second (and later) arguments
are not expanded or evaluated.

I followed the GCC implementation in terms of not modifying the
behavior of `__builtin_va_start` (it still requires exactly two
arguments), but this approach has led to several QoI issues that I've
documented with FIXME comments in the test. Specifically, the
requirement that we do not evaluate *or expand* the second and later
arguments means it's no longer possible to issue diagnostics for
compatibility with older C versions and C++. I am reaching out to
folks in WG14 to see if we can get an NB comment to address these
concerns (the US comment period has already closed, so I cannot file
the comment myself), so the diagnostic behavior may change in the
future.

I took this opportunity to add some documentation for all the related
builtins in this area, since there was no documentation for them yet.

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

The aim of this patch is to minimize the compilation time overhead of
running Function Specialization. It is about 40% slower to run as a
standalone pass (IPSCCP + FuncSpec vs IPSCCP with FuncSpec) according
to my measurements. I compiled the llvm testsuite with NewPM-O3 + LTO
and measured single threaded [user + system] time of IPSCCP and FuncSpec
by passing the '-time-passes' option to lld. Then I compared the two
configurations in terms of Instruction Count of the total compilation
(not of the individual passes) as in https://llvm-compile-time-tracker.com.
Geomean for non-LTO builds is -0.25% and LTO is -0.5% approximately.

You can find more info below:

https://discourse.llvm.org/t/rfc-should-we-enable-function-specialization/61518

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

The LLVMipo library no longer depends on the Scalar component.
The shared functions between IPSCCP and SCCP have been moved
under Utils, in the SCCPSolver.

This is preliminary work for D126455, in order to break a cyclic
dependency between LLVM libraries.

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

Hardware single stepping is not currently supported by the linux kernel.
In order to support single step debugging, add EmulateInstructionLoongArch
to implement the software Single Stepping. This patch only support the
simplest single step execution of non-jump instructions.

Reviewed By: SixWeining, DavidSpickett

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

This reverts commit 3a9e07b1.

Reason to revert: author name is wrong.

This teaches the DemandedElts version of isConstOrConstSplat about
SPLAT_VECTORS, in the same way as the non-DemandedElts version by
calling the demanded-bits version from the non-demanded-bits version.

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

This test is executed with config enabled, and it fails if there is an
extra (-Wnewline-eof) compile flag from the user config.

A few more that I missed in commit 3528e63d.

There could be more duplicates remaining, since I've only focused
on exactly duplicated "RUN: opt" lines (ignoring multi line RUN
lines ending with '\').

The same functionality is already implemented in the
readability-static-definition-in-anonymous-namespace
check, including automatic fixes.

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

msvc fails to link when using any_cast. This seems to be fixed recently
only.

https://developercommunity.visualstudio.com/t/stdany-doesnt-link-when-exceptions-are-disabled/376072

This reverts commit aeac2e48.

Hardware single stepping is not currently supported by the linux kernel.
In order to support single step debugging, add EmulateInstructionLoongArch
to implement the software Single Stepping. This patch only support the
simplest single step execution of non-jump instructions.

Reviewed By: SixWeining, DavidSpickett

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

llvm::Any had several bugs in the past, due to being sensitive to symbol
visibility. (See D101972 and D108943)

Even with these fixes applied, I still encounter the same issue on
Windows.

Similar to llvm::Optional going away in favor of std::optional, we can
use std::any from C++17.

Using std::any fixes the problem and puts the burden to do it correctly
on the standard library.

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

In case of unaligned nop sequences, pad to the nearest 4-byte boundary
with zeros before filling with `nop` instructions. This is consistent
with gas behavior, and is necessary to compile the Linux kernel with
LLVM IAS.

Replace `support::endian::write` with `OS.write` while at it. This is
simpler and correct because we only have little endian.

Reviewed By: SixWeining, xen0n

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

Fix: https://github.com/llvm/llvm-project/issues/59251
Differential Revision: https://reviews.llvm.org/D139087

We cannot remove an insertvalue of undef if it inserts into a
potentially poison value. The new implementation matches that of
insertelement.

See https://alive2.llvm.org/ce/z/pCcFsW for the previously
incorrect transform.

This reverts commit f9e03907.

The patch causes a crash for the IR below:

target datalayout = "e-m:o-i64:64-i128:128-n32:64-S128"
target triple = "arm64-apple-macosx"

define void @test(ptr %data, <8 x i16> %v) {
entry:
  %0 = sext <8 x i16> %v to <8 x i32>
  %1 = mul <8 x i32> %0, <i32 35584, i32 35584, i32 35584, i32 35584, i32 35584, i32 35584, i32 35584, i32 35584>
  %2 = lshr <8 x i32> %1, <i32 1, i32 1, i32 1, i32 1, i32 1, i32 1, i32 1, i32 1>
  %3 = trunc <8 x i32> %2 to <8 x i16>
  store <8 x i16> %3, ptr %data, align 2
  ret void
}