The old LoopUnswitch pass unswitched selects, but the changes were
never ported to the new SimpleLoopUnswitch.

We unswitch by turning:

``` S = select %cond, %a, %b ```

into:

``` head: br %cond, label %then, label %tail

then: br label %tail

tail: S = phi [ %a, %then ], [ %b, %head ] ```

Unswitch selects are always nontrivial, since the successors do not
exit the loop and the loop body always needs to be cloned.

Unswitch selects always need to freeze the conditional if the
conditional could be poison or undef. Selects don't propagate
poison/undef, and branches on poison/undef causes UB.

Reland 1 - Fix the insertion of freeze instructions. The original
implementation inserts a dead freeze instruction that is not used by the
unswitched branch.

Reland 2 - Include https://reviews.llvm.org/D149560 in the same patch,
which was originally reverted along with this patch. The patch prevents
unswitching of selects with a vector conditional. This could have been
caught in SimpleLoopUnswitch/crash.ll if it included tests for
nontrivial unswitching. This reland also adds a run for the test file
with nontrivial unswitching.

Reviewed By: nikic, kachkov98, vitalybuka

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

All we need is the suffix indices.

Just store those instead.

Also improve code readability a little while we're here.

- Move comment to top of file
- Remove unused vector include

Add:

- SuffixTreeNode.h
- SuffixTreeNode.cpp

The SuffixTree file was getting too long.

This makes it clearer that EmptyIdx is related to the node.

Also add an allocator for the root so that in the main SuffixTree code we don't
see gross stuff like a nullptr parent etc.

/data/llvm-project/compiler-rt/lib/xray/../../include/xray/xray_records.h:48:24: error: default member initializer for bit-field is a C++20 extension [
-Werror,-Wc++20-extensions]
  bool ConstantTSC : 1 = false;
                       ^
/data/llvm-project/compiler-rt/lib/xray/../../include/xray/xray_records.h:49:23: error: default member initializer for bit-field is a C++20 extension [
-Werror,-Wc++20-extensions]
  bool NonstopTSC : 1 = false;
                      ^
2 errors generated.

Element-wise exp(log) can be canonicalized as no-op.

Reviewed By: eric-k256

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

and also adds description for default fp environment.

Reviewed By:rjmccall, sepavloff
Differential Revision: https://reviews.llvm.org/D146188

MemRefMem2Ref was unnecessarily including a header from Complex and not
including it as a cmake dep (causing some builds to fail).

Looks like code assumes that it will be always set, but it's not true:
https://reviews.llvm.org/D150420. This is temporarily suppression to enabled
stricter msan on a bot.

Revert "[SystemZ][z/OS] Save (and restore) R3 to avoid clobbering parameter when call stack frame extension is invoked"

This reverts commit 1aec3d15.

LLParser::parseInstruction speculatively getUIntVal()
but uses that only in some branches.

APFloatVal, TyVal and StrVal were already initialized, when
UIntVal and APSIntVal were not.

Reviewed By: craig.topper

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

Avoids reports with msan -fno-inline.

I tried to build libFuzzer for RISC-V and succeeded. All the libFuzzer
targets were successfully built. I tested this on the small hello world code
with a few branches to check the instrumentation; all of them were covered by
libFuzzer on RISC-V arch. So I suppose it makes sense to enable libFuzzer
build for RISC-V.

Reviewed By: phosek, thetruestblue, MaskRay

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

[SystemZ][z/OS] Save (and restore) R3 to avoid clobbering parameter when call stack frame extension is invoked

When the stack frame extension routine is used, the contents of r3 is
overwritten. However, if r3 is live in the prologue (ie. one of the
function's parameters resides in r3), it needs to be saved. We save
r3 in r0 if r0 is available (ie. r0 is not used as temporary storage
for r4), and in the corresponding stack slot for the third parameter otherwise.

Reviewed By: uweigand

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

Following guidelines in

https://llvm.org/docs/HowToSetUpLLVMStyleRTTI.html

This allows us to

* Quickly discern between leaf and internal nodes
* Be more idiomatic with the rest of LLVM
* Save some size on node structs
* Reduce the number of allocations (because end indices for internal nodes no
  longer need to be pointers to be compatible with leaf nodes)

Also object orientify the code some more. This allows for more asserts and
checks.

This shouldn't impact code size on the MachineOutliner.

- All unit tests pass (outliner lit + llvm-unit)
- No code size changes on CTMark @ -Oz for AArch64

up at runtime using dlsym

Calling dlsym with RTLD_DEFAULT can be very slow as all images in the
process are searched for the symbol.

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

It uses to initialize the class. If so, it returns uninitalized value.
This is UB and msan with -fno-inline will complain.

We were missing any support for ISD::INTRINSIC_W_CHAIN/INTRINSIC_VOID
used for memory operations.

For ISD::PREFETCH and target memory nodes we didn't add the subclass
data.

This patch handles all MemIntrinsicSDNode in one place and adds the
missing subclass data.

Note. Unlike load/stores we don't add the memory VT in AddNodeIDCustom or getMemIntrinsicNode. Not sure why.

Reviewed By: efriedma

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

I can't figure out how to reproduce this for test, but I see the case on
random binaries.

The known issue is with GLIBC, others may have a workaround, e.g. Bionic,
https://cs.android.com/android/platform/superproject/+/master:bionic/libc/bionic/pthread_exit.cpp;l=149
see signals blocked above.

Reviewed By: eugenis

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

Fixes false leaks on thread retval.

Reviewed By: thurston

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

ThinLTO imports (which appear as `available_externally`) that survive
inlining get deleted. With today's inliner that's reasonable, because
the way the function would be inlined into in other modules would be the
same - because of the bottom-up traversal assumption, and the fact that
the inliner doesn't take into account surrounding context [*]. The
ModuleInliner invalidates the first assumption, and the ML inliner the
second.

This patch adds a way to opt-in a module to keep its variant of an
imported function, even if it survived past inlining.

[*] Almost. Deferred inlining is an exception which can lead to
(empirically) infrequent discrepancies.

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

Fixes false leaks on thread retval.

Reviewed By: thurston

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

Reviewed By: wrengr

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

`DoubleAPFloat` has a `unique_ptr<APFloat[]>` member. In
`DoubleAPFloat::operator=` and `DoubleAPFloat::get{First,Second}`,
the methods of this unique_ptr are getting instantiated. At that
point `APFloat` is still only a forward declaration.

This triggers undefined behavior. So far, we were probaly just
lucky and the code compiled fine. However, with C++23
`std::unique_ptr` became constexpr, and clang (and other compilers) are
now diagnosing this latent bug as an error.

This commit fixes the issue by moving the function definitions
out of the class definition of `DoubleAPFloat`, after the declaration
of `APFloat`.

A similar issue exists in `ModuleSummaryIndex.h`, the fix is pretty
much identical.

Fixes #59784

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

Update _OPENACC definition to be consistent with the flang-new
driver. Currently set to 202011 which is OpenACC 3.1 specification and
is the current parser/semantic status.

Reviewed By: razvanlupusoru

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

Fixes false leaks on thread arg, retval.

Reviewed By: Enna1

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

Typically GPUs cannot access memory in sub-byte manner. So for
sub-byte integer type values, we need to either expand them to
full bytes or tightly pack them. This commit adds support for
tightly packed power-of-two sub-byte types.

Sub-byte types aren't allowed in SPIR-V spec, so there are no
compute/storage capability for them like other supported integer
types. So we don't recognize sub-byte types in `spirv::ScalarType`.
We just special case them in type converter and always convert
to use i32 under the hood.

Reviewed By: kuhar

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

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

The acc.host_data operation models the OpenACC
host_data construct (2.8). The host_data construct
defines a region where the address of data in device memory
available on the host. The operation is modeled in a similar way
than acc.data operation.

Reviewed By: razvanlupusoru, jeanPerier

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

Instead of calling _FortranASizeDim, we can instead load extent
directly from descriptor. Add this support for cases where dim
is a known constant at compile time.

Reviewed By: clementval

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

wrong answer. Plus, it's useful in some places to have a way to force
the full stack to be created even in the face of
interruption. Moreover, most of the time when you're just getting
frames, you don't need to know the number of frames in the stack to
start with. You just keep calling
Thread::GetStackFrameAtIndex(index++) and when you get a null
StackFrameSP back, you're done. That's also more amenable to
interruption if you are doing some work frame by frame.

So this patch makes GetStackFrameCount always return the full count,
suspending interruption. I also went through all the places that use
GetStackFrameCount to make sure that they really needed the full stack
walk. In many cases, they did not. For instance frame select -r 10 was
getting the number of frames just to check whether cur_frame_idx + 10
was within the stack. It's better in that case to see if that frame
exists first, since that doesn't force a full stack walk, and only
deal with walking off the end of the stack if it doesn't...

I also added a test for some of these behaviors.

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

We need something to keep arg and retval pointers for leak checking.
Pointers should keept alive even after thread exited, until the thread
is detached or joined.
We should not put this logic into ThreadRegistry as we need the the
same for the ThreadList of HWASAN.

Reviewed By: thurston

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