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

Add C and python bindings for InferShapedTypeOpInterface
and ShapedTypeComponents. This allows users to invoke
InferShapedTypeOpInterface for ops that implement it.

Reviewed By: ftynse

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

https://reviews.llvm.org/rGc5b94ea265133a4a28006929643155fc8fbeafe6 allows N >= 10.

Apply missed cleanups.

Reviewed By: kuhar

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

The AMDGPU linker is `lld`, which has full support for standard features
like static libraries. Previously the AMDGPU toolchain did not forward
`-L` arguments so we could not tell it where to find certain libraries.
This patch simply forwards it like the other toolchains.

Reviewed By: yaxunl, MaskRay

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

When generating code for the epilogue vector loop, we need to re-use the
expansion results for induction steps generated for the main vector
loop, as the pre-header of the epilogue vector loop may not dominate the
vector preheader of the epilogue.

This fixes a reported crash. Note that this is a workaround which should
be removed soon once induction resume value creation is handled in VPlan
directly.

Reviewed By: kuhar

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

This allows backends to customize arbitrary parallel algorithms, which was requested pretty often.

Reviewed By: #libc, ldionne

Spies: arichardson, miyuki, crtrott, dalg24, __simt__, philnik, libcxx-commits

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

For the "C" Standard Extension/Zca, D45560 enabled 2-byte alignment for
assembly output (e.g. `clang -S a.c`) and D102052 enabled 2-byte alignment for
assembly input and object file output (e.g. `clang -c a.s`).

This patch ports the behavior for code generation and object file output by
adding RISCVELFTargetObjectFile::getTextSectionAlignment (e.g. `clang -c a.c`).

Reviewed By: craig.topper

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

Stop reordering the pointers passed in ProvenanceAnalysis::related based
on their values. That was causing non-determinism as the call to
relatedCheck(A, B) isn't guaranteed to return the same result as
relatedCheck(B, A).

Revert the following three commits (except the original test case in
related-check.ll):

665e4777
29586151
d877e3fe

These changes shouldn't be necessary once the call to std::swap is
removed.

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

When `disassemble --mixed` is run, do not show source for line zero, as intended.

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

According to the spec, RestartRequest has an optional "arguments" field, which
is a RestartArguments object. RestartArguments has its own optional "arguments"
field, which is a (LaunchRequestArguments | AttachRequestArguments) object. So
we need to to the "arguments" lookup twice to get to the actual launch
arguments.

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