This reverts commit 5bb826d5.

We suspect this is leading to the segfaults for tests run on
aarch64+android+hwasan:
https://lab.llvm.org/buildbot/#/builders/77/builds/26025/steps/21/logs/stdio

Reviewed By: aartbik, wrengr

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

Like CUDA and OpenCL, the SYCL specification says that throwing and
catching exceptions in device functions is not supported, so this change
extends the logic for adding the NoUnwind attribute to SYCL.

The existing convergent.cpp test, which tests that the convergent
attribute is added to functions by default, is renamed and reused to
test that the nounwind attribute is added by default. This test now has
-fexceptions added to it, which the driver adds by default as well.

The obvious question here is why not simply change the driver to remove
-fexceptions. This change follows the direction given by the TODO
comment because removing -fexceptions would also disable the
__EXCEPTIONS macro, which should reflect whether exceptions are enabled
on the host, rather than on the device, to avoid conflicts in types
shared between host and device.

Reviewed By: bader

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

This commit contains several code changes which are ultimately required for converting the varions `Merger` identifiers from typedefs to newtypes.  The actual implementation of the newtypes themselves has been split off into separate commits, in hopes of simplifying the review process.

Depends On D146561

Reviewed By: aartbik

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

bf16 has a trivial truncation/extension behavior with F32 that
can be described in elementary arith operations. Include some
expansions to efficiently convert.

Reviewed By: jpienaar

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

[DAG][RISCV] Allow scalable vector ISD::STRICT_FP_ROUND and support vector ISD::STRICT_FP_ROUND for RISC-V.

The patch customized lower vector type ISD::STRICT_FP_ROUND to RISCVISD::STRICT_FP_ROUND.

Reviewed By: craig.topper

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

This reverts commit b66a6e4b which
breaks runtime tests.

This diff implements minimal block coverage instrumentation. When the `-pgo-block-coverage` option is used, basic blocks will be instrumented for block coverage using single byte booleans. The coverage of some basic blocks can be inferred from others, so not every basic block is instrumented. In fact, we found that only ~60% of basic blocks need to be instrumented. These differences lead to less size overhead when compared to instrumenting block counts. For example, block coverage on the clang binary has an overhead of 20 Mi (17%) compared to 56 Mi (47%) with block counts.

Even though block coverage profiles have less precision than block count profiles, they can still be used to guide optimizations. In `PGOUseFunc` we use block coverage to populate edge weights such that BFI gives nonzero counts to only covered blocks. We do this by 1) setting the entry count of covered functions to a large value, i.e., 10000 and 2) populating edge weights using block coverage. In the next diff https://reviews.llvm.org/D125743 we use BFI to guide the machine outliner to avoid outlining covered blocks. This `-pgo-block-coverage` option provides a trade off of generating less precise profiles for faster and smaller instrumented binaries.

The `BlockCoverageInference` class defines the algorithm to find the minimal set of basic blocks that need to be instrumented for coverage. This is different from the Kirchhoff circuit law optimization that is used for edge **counts** because that does not work for block **coverage**. The reason for this is that edge counts can be added together to find a missing count while block coverage cannot since they store boolean values. So we need a new algorithm to find which blocks must be instrumented.

The details on this algorithm can be found in this paper titled "Minimum Coverage Instrumentation": https://arxiv.org/abs/2208.13907

Special thanks to Julian Mestre for creating this block coverage inference algorithm.

Binary size of `clang` using `-O2`:

* Base
  * `.text`: 65.8 Mi
  * Total: 119 Mi
* IRPGO (`-fprofile-generate -mllvm -disable-vp -mllvm -debug-info-correlate`)
  * `.text`: 93.0 Mi
  * `__llvm_prf_cnts`: 14.5 Mi
  * Total: 175 Mi
* Minimal Block Coverage (`-fprofile-generate -mllvm -disable-vp -mllvm -debug-info-correlate -mllvm -pgo-block-coverage`)
  * `.text`: 82.1 Mi
  * `__llvm_prf_cnts`: 1.38 Mi
  * Total: 139 Mi

Reviewed By: spupyrev, kyulee

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

llvm-debuginfod intrinsically requires cpp-httplib to operate, so
exclude the target if it's unavailable. Right now the tool walks off an
llvm_unreachable.

Reviewed By: phosek

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

These were required by the llvmlibc linter.

Reviewed By: sivachandra

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

Preparation for adding the other RVV load/store intrinsics we use
for the C API.

Reviewed By: asb, kito-cheng

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

broke this build since I forgot to wrap the moved struct in the
`__sanitizer` namespace so uptr wasn't refering to __sanitizer::uptr.

It was only in RISCVInstrInfo because it was used by 2 passes, but those
passes have been merged in D147173.

Reviewed By: asb

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

These run together in the pipeline and are the only users of
TII.hasAllWUsers. Merging them will allow us to move hasAllWUsers
back from TII.

Reviewed By: asb

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

rdar://107364766

Given the intent of Split DWARF is to minimize .o file size it seems
like adequate signal that it's worth a minor tradeoff in .dwo size to
significantly reduce .o size (though it doesn't reduce linked executable
size - the cost is mostly in the static relocations resolved by the
linker).

Sink/share a few common conditions.

Fixes a build warning caused by D146744.

I've seen a couple of request for extra Json formatting to match prettier capability.

Reviewed By: owenpan

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

{D144170} didn't go via the normal clang-format reviewers and we'd have pointed out that this list of options remains sorted.

Reviewed By: owenpan

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

Fixes https://github.com/clangd/clangd/issues/1554

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

It appears we've been incorrectly stripping CV qualifiers when capturing `this` by value inside lambdas.
This patch simply removes the CV stripping code as discussed.

Closes https://github.com/llvm/llvm-project/issues/50866

Reviewed By: #clang-language-wg, cor3ntin, aaron.ballman

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

Previously the check to just return MAX or MIN used the caclulated
number being the maximum absolute value. This was right in every case
except for an unsigned conversion being passed its maximum value with a
negative sign on the front. This should return -MAX, but was returning
just MAX.

Reviewed By: lntue

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

As discussed earlier in the [GitHub
issue](https://github.com/llvm/llvm-project/issues/59500), currently
LLVM generates invalid code when emulated TLS is used. There were
attempts to resolve this previously (D102527), but they were not merged
because the component owners raised concerns about emulated TLS
efficiency.

The current state of the art is that:

- OpenBSD team, which raised the initial issue, simply has [patches
  downstream](https://github.com/openbsd/src/blob/a0747c9/gnu/llvm/llvm/lib/Target/RISCV/RISCVISelLowering.cpp#L2850-L2852).
- Our team, which raised the GH issue, has patches downstream as well.
  We also do not use `malloc` or any [dynamic
allocations](https://github.com/llvm/llvm-project/issues/59500#issuecomment-1349046835)
with emulated TLS, so the concerns raised in the original issue does not
apply to us.
- GCC compatibility is broken, because GCC supports emulated TLS.
- RISC-V is the only architecture in LLVM that does not support emulated
  TLS, and work is being done to at least warn the users about it
(D143619).

With all these in mind I believe it is important to address the
consumers' needs especially given that there is little to no maintenance
downsides.

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

We already had vector.transpose(vector.create_mask) ->
vector.create_mask. This patch adds the constant mask version of it.

Reviewed By: nicolasvasilache

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

This is a variant of the existing `mapIterationSpaceDimToOperandDim`.
We have a local use downstream.

Reviewed By: nicolasvasilache

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

linalg.fill was already vectorizable with masks but not supported in the
dynamic pre-checks.

Reviewed By: nicolasvasilache

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

This patch removes the historical lhs and rhs masks in vector.contract,
now that vector.mask supports vector.contract and the lhs and rhs masks
are barely supported by all the vector.contract lowerings and
transformations.

Reviewed By: nicolasvasilache

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

In `DebugValueManager`, if a `Def` is requested to be sunk to the same
place (i.e., `Insert` is right after `Def`, not counting `DBG_VALUE`s)
currently we still do the sink. This can result in unnecessary creation
of `DBG_VALUE $noreg`. See comments for details. This CL detects this
case and do nothing and return, so we don't end up creating unnecessary
undef `DBG_VALUE`s.

Reviewed By: dschuff

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

The current `DebugValueManager`, which is mostly used in `RegStackify`,
simply sinks `DBG_VALUE`s along when a def instruction sinks.
(`RegStackify` only does sinks; it doesn't do hoists.)

But this simple strategy can result in incorrect combinations of
variables' values which would have not been possible in the original
program. In this case, LLVM's policy is to make the value unavailable,
so they will be shown as 'optimized out', rather than showing inaccurate
debug info. Especially, when an instruction sinks, its original
`DBG_VALUE` should be set to undef. This is well illustrated in the
third example in
https://llvm.org/docs/SourceLevelDebugging.html#instruction-scheduling.

This CL rewrites `DebugValueManager` with this principle in mind. When
sinking an instruction, it sinks its eligible `DBG_VALUE`s with it, but
also leaves undef `DBG_VALUE`s in the original place to make those
variables' values undefined.

Also, unlike the current version, we sink only an eligible subset of
`DBG_VALUE`s with a def instruction. See comments in the code for
details.

In case of cloning, because the original def is still there, we don't
set its `DBG_VALUE`s to undef. But we clone only an eligible subset of
`DBG_VALUE`s here as well.

One consequence of this change is that now we do sinking and cloning of
the def instruction itself within the `DebugValueManager`'s `sink` and
`clone` methods. This is necessary because the `DebugValueManager` needs
to know the original def's location before sinking and cloning in order
to scan other interfering `DBG_VALUE`s between the original def and the
insertion point. If we want to separate these two, we need to call
`DebugValueManager`'s `sink` and `clone` methods //before//
sinking/cloning the def instruction, which I don't think is a good
design alternative either, because the user of this class needs to pay
extra attention when using it.

Because this change is fixing the existing inaccuracy of the current
debug info, this reduces the variable info coverage in debug info, but
not by a large margin. In Emscripten core benchmarks compiled with
`-O1`, the coverage goes from 56.6% down to 55.2%, which I doubt will be
a noticeable drop. The compilation time doesn't have any meaningful
difference either with this change.

Reviewed By: dschuff

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

The stdio test failures were due to headers potentially not being built
in the correct order. This should set up the dependencies correctly.

Reviewed By: sivachandra

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

It is recommended to use `SmallVectorImpl`/`ArrayRef` over
`SmallVector<TypeName, N>` for function parameters:
https://llvm.org/docs/ProgrammersManual.html#llvm-adt-smallvector-h

Reviewed By: dschuff

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

Currently calling stack locations is selected using `CALL` in ISel,
resulting in an invalid code and crashing in AsmPrinter. FastISel
correctly selects it will `CALL_INDIRECT`.

Fixes the problem reported in D146781.

Reviewed By: tlively, HerrCai0907

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

An INLINEASM can have an implicit def of vcc. It is not appropriate for
fixImplicitOperands to change this to vcc_lo on wave32.

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

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

Summary:
The AMDGPU ABI isn't stable or well defined. For that reson we prefer to
rely on LTO to ensure that multiple files get linked correctly.
Currently the internal targets used for testing mix LLVM-IR and
assembly. We should be consistent here.

Mark test added in D141824 as unsupported for PS4/PS5 as those platforms require an external linker that is not present.