Fixes createInstrument to return instrument when LMUL data is valid, and
return nullptr when LMUL data is not valid for RISCV target.

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

Reported after D149234.

Does not fix the leak.

This reverts commit 15334786.

This patch addresses 2 problems:

- In `ShuffleBlockStrategy`, when `BB` is an EHPad, `BB.getFirstInsertionPt()` will return `BB.end()`, which cannot be dereferenced and will cause crash in following loop.
- In `isCompatibleReplacement`, a call instruction's callee might be replaced by a pointer, causing 2 subproblems:
  - we cannot guarantee that the pointer is a function pointer (even if it is, we cannot guarantee it matches the signature).
  - after such a replacement, `getCalledFunction` will from then on return `nullptr` (since it's indirect call) which causes Segmentation Fault in the lines below.

This patch fixes the first problem by checking if a block to be mutated is an EHPad in base class `IRMutationStrategy` and skipping mutating it if so.

This patch fixes the second problem by avoiding replacing callee with pointer and adding a null check for indirect calls.

Reviewed By: Peter

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

The .cfi_sections .debug_frame intrinsic is used to emit .debug_frame
section. This directive tells the assembler to write out a section of
debug frame data. AArch64 is a platform where eh_frame is not needed for
unwind information. Unfortunately, that means that even when the
.cfi_sections .debug_frame intrinsic is used, the compiler skips
emitting the CIE's and FDE's in the debug_frame section. This patch
address that issue by making sure that the emission of CIE's and FDE's
are only skipped if the unwind information does not require a
debug_frame section and is a platform where the eh_frame can be skipped.

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

There was some lacking test coverage for checking when the
.cfi_sections .debug_frame intrinsic is emitted. On x86_64,
with -fno-exceptions there is no .cfi_sections .debug_frame intrinsic
emitted because there is an unwind table attribute.

On AArch64, with -fno-exceptions, there is no unwind table attribute, so
the .cfi_sections .debug_frame intrinsic is emitted correctly.

Alternatively, with -fexceptions, both AArch64 and x86_64 emit an unwind
table and therefore do not emit a .cfi_sections .debug_frame intrinsic

All this work was done in addition to https://reviews.llvm.org/D139663
patch.

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

Reported after D149234.

The existing LibcTestMain has been renamed to LibcUnitTestMain.
Hermetic tests are linked to LibcHermeticTestMain and unit tests are
linked to LibcUnitTestMain.

Reviewed By: jhuber6

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

These don't really need to be in ConstStrings. It's nice that comparing
ConstStrings is fast (just a pointer comparison) but the cost of
creating the ConstString usually already includes the cost of doing a
StringRef comparison anyway, so this is just extra work and extra memory
consumption for basically no benefit.

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

Make sure that the upper bits of the offset is placed in bits 20-21 of the
instruction word.

This fixes the encoding of backwards (negative offset) BPr branches.

(Previously, the upper two bits of the offset would overwrite parts of the rs1
field, causing it to branch on the wrong register, with the wrong offset)

Reviewed By: arsenm

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

On 64-bit target, when doing i64 BR_CC where one of the comparison operands is a
constant zero, try to fold the compare and BPcc into a BPr instruction.

For all integers, EQ and NE comparison are available, additionally for signed
integers, GT, GE, LT, and LE is also available.

Reviewed By: arsenm

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

Currently memory attributions are not supported for gpu::LaunchOp, this patch implements memory attributions for gpu::LaunchOp and modifies the KernelOutlining pass to make the attributions available in GPUFuncOp.

Reviewed By: makslevental

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

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

This patch wants to fix inline friend decl like
```
template <class F1> int foo(F1 X);
template <int A1> struct A {
  template <class F1> friend int foo(F1 X) { return A1; }
};

template struct A<1>;
int a = foo(1.0);
```

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

Reviewed By: kstoimenov, eugenis

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

This is leftover from older version of HWASAN.
The current HWASAN assumes that the new stack
frames are tagged with zeroes, which make getNextTagWithCall
or StackTag ^ TagMaskByte unusable.

Reviewed By: kstoimenov, eugenis

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

Summary:
This patch makes this only apply to the GPU build. This should be
handled more intelligently in the future so it's common between all of t
hem.

Address Dave's post-commit review feedback from
https://reviews.llvm.org/D147736#inline-1441914

Summary:
This is a little broken, what we really need is a separate target to use
with the hermetic tests, but this is a stop-gap to get the bots green
again.

Jason isn't sure what this is used for and isn't aware of a .Bundle
suffix related to kernel debugging. Let's remove it.

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

The `atexit` function controls registering functions to call at the end
of the program. This is difficult to do in general on the GPU because of
the lack of a real mutex implementation. We primarily provide this for
testing where we can explicitly restrict how the `atexit` registration
functions are called. So we simply create a passthrough Mutex to get
past the usage of it as per @sivachandra's suggestion.

Depends on D149225

Reviewed By: sivachandra

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

We need to perform the GPU build separately. The `CXX_STANDARD` option
was not being passed properly.

Reviewed By: sivachandra

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

The previous patch in D149216 allows us to use the internal `<stdlib.h>`
include for the GPU build. However, we currently don't provide the
memory functions so the header wasn't resolving them. This patch adds
these as entrypoints. They don't cause any entrypoints to be emitted
because they are not implemented, but they provide it in the header so
that we can rely on the test's implementation of them.

Depends on D149216

Reviewed By: sivachandra

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

The generated header files live in the build directory's include path.
When targeting a hermetic build we want to make sure we only use headers
generated by the project itself if availible.

Reviewed By: sivachandra

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

The secondary allocator calls mmap which should return zero-inited pages, so we
don't need to explicitly memset it with zeros. This is similar to what asan's
calloc does.

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

This patch adds targets for printf and fprintf to the bazel build.
Additionally, it adds support for the build system to specify where
files should be written for testing purposes. This was necessary to
enable the fprintf test under bazel.

Reviewed By: sivachandra

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

The call didn't have the right calling convention, but calls to
kernels are supposed to be illegal anyway.

A neon smull/umull should be preferred over a sve v2i64 mul with two extends.
It will be both less instructions and a lower cost multiply instruction.

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

Some tests of D149234 deppend on
aliasing mode.

Fix uninitialied value use introduced in d3f9388f

These are from the N extension (User-Level Interrupts) which did
not make it into 1.12 of the Privileged Specification.

D117653 also tried to remove some of these, but it was never reviewed.

Reviewed By: jrtc27

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

--remap-inputs-file= can be specified multiple times, each naming a
remap file that contains `from-glob=to-file` lines or `#`-led comments.
('=' is used a separator a la -fdebug-prefix-map=)
--remap-inputs-file= can be used to:

* replace an input file. E.g. `"*/libz.so=exp/libz.so"` can replace a resolved
  `-lz` without updating the input file list or (if used) a response file.
  When debugging an application where a bug is isolated to one single
  input file, this option gives a convenient way to test fixes.
* remove an input file with `/dev/null` (changed to `NUL` on Windows), e.g.
  `"a.o=/dev/null"`. A build system may add unneeded dependencies.
  This option gives a convenient way to test the result removing some inputs.

`--remap-inputs=a.o=aa.o` can be specified to provide one pattern without using
an extra file.
(bash/zsh process substitution is handy for specifying a pattern without using
a remap file, e.g. `--remap-inputs-file=<(printf 'a.o=aa.o')`, but it may be
unavailable in some systems. An extra file can be inconvenient for a build
system.)

Exact patterns are tested before wildcard patterns. In case of a tie, the first
patterns wins. This is an implementation detail that users should not rely on.

Co-authored-by: Marco Elver <elver@google.com>
Link: https://discourse.llvm.org/t/rfc-support-exclude-inputs/70070

Reviewed By: melver, peter.smith

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

Reviewed By: ldionne, #libc

Spies: libcxx-commits, arichardson

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

flang cannot be built with exceptions enabled. Doing so results in a link-time
error.

This addresses issue #59353 [https://github.com/llvm/llvm-project/issues/59353]

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

The sanity check on the size of the register context we found in
the corefile was off by one, so lldb would not add the register
contents.  Add a test case to ensure it doesn't regress.

Differential Revision: https://reviews.llvm.org/D149224
rdar://108306070