Adds a target hook canPredicatePredicatedInstr(const MachineInstr&) that
assumes an instruction is already predicated and returns true if it can
be predicated again, used by the early if-conversion pass in order to
iterate multiple times on architectures supporting predicate logic.

No test added since there is no upstream target that can take advantage.

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

Changes all unqualified calls to __throw_format_error to use a qualified
call.

Reviewed By: #libc, philnik

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

Reviewed By: bixia

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

Reviewed By: python3kgae

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

The other operands in this function had it and every other test
in the file has it. So I assume this was a mistake.

This patch adds support for including binary ids in an indexed profile.
It adds a new field into the header that points to the offset of the
binary id section. The binary id section consists of a size of the
section, and a list of binary ids (if they are present) that consist
of two parts: length and data.

This patch guarantees that indexed profile is backwards compatible
after adding binary ids.

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

Fixes issue 59413.

On RV64 these instructions produce a 32-bit value and sign extend
to 64-bits.

Reviewed By: reames

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

Avoid calling separate isa<> and cast<> if we can - dyn_cast<> can more efficiently check for a safe cast and give the casted pointer.

This is a clean up following the revision D139868 (https://reviews.llvm.org/D139868).

Reviewed By: gribozavr2, ymandel

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

[GVN] hasUsersIn - merge isa<> and cast<> into single dyn_cast<> and convert for-range loop to any_of() test. NFCI.

Avoid running isa<> and cast<> if we can - dyn_cast<> can more efficiently check for a safe cast and give the casted pointer.

Shadow memory was not marked as non-dumpable after a reset resulting in process taking a very long time to generate a coredump.

Reviewed By: vitalybuka

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

These tests covers mulf, ori, and subi.

NFC

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

This is a follow up to patch discussion on D139656. As noted there, M2/M4/M8 versions of these instructions don't actually exist, and using them results in overly constrained register allocation.

In that review, we'd talked about moving towards a variant of the instructions which ignored LMUL. I decided to see what happened if we just stopped generating the high LMUL variants, and the results are surprisingly neutral. I only see one minor thing which looks like a real regression among all the churn. I think this is worth doing now to loosen register allocation constraints, and avoid digging our hole around these instructions deeper while thinking about the right model change.

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

This is part of a series of patches that aim at making Function::getBasicBlockList() private.

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

Don't touch FileCheck.cpp:698 StringSwitch<Optional<binop_eval_t>>(FuncName).
MSVC and older GCC may report errors:

error C2664: 'llvm::StringSwitch<std::optional<llvm::binop_eval_t>,T> &llvm::StringSwitch<T,T>::Case(llvm::StringLiteral,T)': cannot convert argument 2 from 'overloaded-function' to 'T'
        with
        [
            T=std::optional<llvm::binop_eval_t>
        ]

llvm/lib/FileCheck/FileCheck.cpp:699:44: error: no matching function for call to ‘llvm::StringSwitch<std::optional<llvm::Expected<llvm::ExpressionValue> (*)(const llvm::ExpressionValue&, const llvm::ExpressionValue&)> >::Case(const char [4], <unresolved overloaded function type>)’
                      .Case("add", operator+)
                                            ^

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

Instead of switching on the opcode in SExtWRemoval, we can use a
bit in TSFlags. This reduces the amount of code that needs to be
generated to implement the switch. The opcodes are scattered throughout
the opcode enum, so the switch isn't very densely packed.

Reviewed By: asb

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

The last use of Optional<T>::create was removed on December 10, 2022
in commit 1cb7fba3.

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

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

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

We now have an adequate set of API functions, including BasicBlock::splice(),
BasicBlock::erase(), Instruction::insertAt() etc. that we shouldn't need access
to the underlying instruction list.

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

The operations are converted into LLVM::PowIOp.

Reviewed By: Mogball

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

In https://reviews.llvm.org/D136745 we introduced the "pre-condition"
that offsets should not be -1 or -2. This can easily break. The new
special values are INT32_MAX and INT32_MIN, which we might want to
replace with std::optional or flags instead.

The most common case for string attributes parses them as integers. We
don't have a convenient way to do this, and as a result we have
inconsistent missing attribute and invalid attribute handling
scattered around. We also have inconsistent radix usage to
getAsInteger; some places use the default 0 and others use base 10.

Update a few of the uses, but there are quite a lot of these.

This reverts commit 13fd37c9.

This change is causing bot failures on some Windows and older GCC bots:
- https://lab.llvm.org/buildbot/#/builders/123/builds/14678
- https://lab.llvm.org/buildbot/#/builders/216/builds/14436
- https://lab.llvm.org/staging/#/builders/235/builds/993

In scalar plans, replicate recipes will only generate a single value per
UF, independent of whether they are uniform or not. So don't consider
uniformity for plans with scalar VFs only.

This allows us to handle a few additional cases in VPlan sinking instead
of non-VPlan sinkScalarOperands.

Depends on D133762.

Reviewed By: Ayal

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

The affine fusion pass can actually work on the top-level of a `Block`
and doesn't require to be called on a `FuncOp`. Remove this restriction
and generalize the pass to work on any `Block`. This allows fusion to be
performed, for example, on multiple blocks of a FuncOp or any
region-holding op like an scf.while, scf.if or even at an inner depth of
an affine.for or affine.if op. This generalization has no effect on
existing functionality. No changes to the fusion logic or its
transformational power were needed.

Update fusion pass to be a generic operation pass (instead of FuncOp
pass) and remove references and assumptions on the parent being a
FuncOp.

Reviewed By: dcaballe

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

Check for aliases for escaping memrefs check in affine fusion pass.  Fix
`isEscapingMemRef` to handle unknown defining ops for the memref.

Reviewed By: dcaballe

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

This patch better integrates the target nowait functions with the tasking runtime. It splits the nowait execution into two stages: a dispatch stage, which triggers all the necessary asynchronous device operations and stores a set of post-processing procedures that must be executed after said ops; and a synchronization stage, responsible for synchronizing the previous operations in a non-blocking manner and running the appropriate post-processing functions. Suppose during the synchronization stage the operations are not completed. In that case, the attached hidden helper task is re-enqueued to any hidden helper thread to be later synchronized, allowing other target nowait regions to be concurrently dispatched.

Reviewed By: jdoerfert, tianshilei1992

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

Managed to introduce an error when changing code to fix other tests and the unit
test was no adequate due to --nostdlib being passed in in llvm testing
enviroment.
Original diff: https://reviews.llvm.org/D132059

Updated a test to make sure that original address and the new address are
different.

Reviewed By: maksfb, #bolt

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

Will look into the difference now, this is to apease the bots.

Hopefully fixes build after 15a6e3c6

We might not have registered an AA allocated via the bump allocator
and consequently not deallocated it properly.