Reviewed By: ldionne, Quuxplusone, #libc

Spies: Mordante, mgorny, libcxx-commits, arichardson, llvm-commits, arphaman

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

This reverts commit 7605ca85.

It caused an assertion failure in Fuschia.

If a cast is needed when replacing uses with newly created values, the
cast must be inserted after the instruction that defines the new value.

Fixes: SWDEV-321215

Reviewed By: arsenm

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

Get it from the byval type instead.

This is important for compatibility with DialectConversion.

This is an alternative to D118667 that instead of fixing the store
to match phase 1, it tries to detect the mismatch with the expected
value at the end of the block. This inserts a vsetvli after the vse
to satisfy the requirement of the other basic block.

We still have serious design issues in the pass, that is going to
require some rethinking.

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

Revert "[RISCV] Fix a vsetvli insertion bug involving loads/stores." and "[RISCC] Add missing words to comment. NFC"

This reverts commit f943c58c.
and commit 7eb78107.

This introduced a new bug that appears to be easier to hit.

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

We're missing a vsetvli before a vse after a redsum in this test.

This appears to be because the vmv.s.x has a VL of 1, but did not
trigger a vsetvli because it is a scalar move op and any non-zero
VL would work. So it looked at it the predecessors and decided it was
that they all had a non-zero vl. Then the redsum was visited, it
also took the VL from the predecessors since the vmv.s.x and the 4
was found compatible.

Finally we visit the vse and it looks at the BBLocalInfo and sees
that is compatible because it contains a VL of 1 from the vmv.s.x,
the first instruction in the block. BBLocalInfo was not updated
when the vredsum was visited because BBLocalInfo was valid and no
vsetvli was generated.

I think fundamentally the vmv.s.x optimization has the same first
phase and third phase not matching problem that D118667 was trying
to fix for stores.

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

This patch refactors all the existing M68k arithmetic instructions
to use the new VarLenCodeEmitterGen infrastructure.

This patch is tested by the existing MC test cases.

Note that one of the codegen tests needed to be updated because the
ordering of two equivalent instructions were switched.

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

Full write up:
https://gist.github.com/mshockwave/66e98d099256deefc062633909bb7b5b

The existing CodeEmitterGen infrastructure is unable to generate encoder
function for ISAs with variable-length instructions. This patch
introduces a new infrastructure to support variable-length instruction
encoding, including a new TableGen syntax for writing instruction
encoding directives and a new TableGen backend component,
VarLenCodeEmitterGen, built on top of CodeEmitterGen.

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

Remove ARTIFICIAL_VGPR which only existed to make VReg_1 not empty.

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

`ranges_swap_ranges.h` includes `<type_traits>` but does not use anything from
it. So, remove the include.

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

Use a subtarget feature instead of a command line argument to reduce
global state.
We want to enable flat scratch for graphics in some cases and this
doesn't work well with command line options.

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

The module flag to indicate use of hostcall is insufficient to catch
all cases where hostcall might be in use by a kernel. This is now
replaced by a function attribute that gets propagated to top-level
kernel functions via their respective call-graph.

If the attribute "amdgpu-no-hostcall-ptr" is absent on a kernel, the
default behaviour is to emit kernel metadata indicating that the
kernel uses the hostcall buffer pointer passed as an implicit
argument.

The attribute may be placed explicitly by the user, or inferred by the
AMDGPU attributor by examining the call-graph. The attribute is
inferred only if the function is not being sanitized, and the
implictarg_ptr does not result in a load of any byte in the hostcall
pointer argument.

Reviewed By: jdoerfert, arsenm, kpyzhov

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

Add a new llvm.fptrunc.round intrinsic to precisely control
the rounding mode when converting from f32 to f16.

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

Test from https://github.com/llvm/llvm-project/issues/48253.

When generating nested CS profile with all calling contexts of a function duplicated into a base profile under `--generate-merged-base-profiles`, do not recount callee samples when computing profile summary. This fixes the profile summary mismatch between flat cs profile and nested cs profile, for both extbinary and text format.

Reviewed By: wenlei

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

The XPLINK return `b 2(7)` has size 4 bytes, while the Linux return
`br 7` only has size 2 bytes. Thus a new alias is required to have correct
instruction byte count. It also fixes the conditional return code.

Reviewed By: uweigand

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

Avoid the need for a forward declaration.

Cleanup prep for Issue #53760

Reviewed By: #libc, ldionne

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

Reviewed By: #libc, ldionne

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

Replace the *_EXTEND node with the raw operands, this will make it easier to use combineToExtendBoolVectorInReg for any boolvec extension combine.

Cleanup prep for Issue #53760

This avoids using an libc++ internal macro in our tests. This version
doesn't depend on the internal macro but redefines it.

Reviewed By: #libc, ldionne

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

Implement ranges::min_element

Reviewed By: Quuxplusone, Mordante, #libc

Spies: miscco, libcxx-commits, mgorny

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

Add `ranges::in_fun_result`

Reviewed By: Quuxplusone, #libc, var-const

Spies: CaseyCarter, var-const, libcxx-commits, mgorny

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

Dexter saves various files to a new results directory each time it is run
(including when it's run by lit tests) and there isn't a way to opt-out. This
patch reconfigures the behaviour to be opt-in by removing the default
`--results-directory` location. Now results are only saved if
`--results-directory` is specified.

Reviewed By: jmorse

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

If we had some source value we could infer an address space from that
went through a ptrtoint/inttoptr pair, this would fail since bitcast
can't change the address space.

Fixes issue 53665.

It's not the same GEP if the source element type is different.

All paths have already dereferenced the CodeCompleter pointer in the ResultBuilder constructor

All paths have already dereferenced the Prev pointer

All paths have already dereferenced the block pointer

... to use hyphens instead of underscores, making it consistent with
our other substitutions like %no-arg-lld and %lld-watchos.

Reviewed By: keith

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

Discussed here: https://reviews.llvm.org/D119061#3310822

Reviewed By: aaron.ballman

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

OpenCL C 3.0 __opencl_c_subgroups feature is slightly different
then other equivalent features and extensions (fp64 and 3d image writes):
OpenCL C 3.0 device can support the extension but not the feature.
cl_khr_subgroups requires subgroup independent forward progress.

This patch adjusts the check which is used when translating language
builtins to check either the extension or feature is supported.

Reviewed By: Anastasia

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