[Support] Remove unnecessary includes (NFC)

[llvm/unittests] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the am

[llvm/unittests] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...

[InstructionCost] Add saturation support.

This patch makes the operations on InstructionCost saturate, so that when
costs are accumulated they saturate to <max value>.

One of the compelling reasons

[InstructionCost] Add saturation support.

This patch makes the operations on InstructionCost saturate, so that when
costs are accumulated they saturate to <max value>.

One of the compelling reasons for wanting to have saturation support
is because in various places, arbitrary values are used to represent
a 'high' cost, but when accumulating the cost of some set of operations
or a loop, overflow is not taken into account, which may lead to unexpected
results. By defining the operations to saturate, we can express the cost
of something 'very expensive' as InstructionCost::getMax().

Reviewed By: kparzysz, dmgreen

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

show more ...

Reland "Ensure that InstructionCost actually implements a total ordering"

The operator< in the previous attempt was incorrect. It is unfortunate
that this was only caught by the expensive checks.

T

Reland "Ensure that InstructionCost actually implements a total ordering"

The operator< in the previous attempt was incorrect. It is unfortunate
that this was only caught by the expensive checks.

This reverts commit ff1147c3635685ba6aefbdc9394300adb5404595.

show more ...

Revert "Ensure that InstructionCost actually implements a total ordering"

This reverts commit b481cd519e07b3ad2bd3e81c89b0dd8efd68d6bc.

Ensure that InstructionCost actually implements a total ordering

Previously, operator== would consider the actual equality of the pairs
(lhs.Value, lhs.State) == (rhs.Value, rhs.State). However, if

Ensure that InstructionCost actually implements a total ordering

Previously, operator== would consider the actual equality of the pairs
(lhs.Value, lhs.State) == (rhs.Value, rhs.State). However, if an invalid
cost was involved in a call to operator<, only the state would be
compared. Thus, it was not the case that ({2, Invalid} < {3, Invalid} ||
{2, Invalid} > {3, Invalid} || {2, Invalid} == {3, Invalid}).

This patch implements a true total ordering, where cost state is
considered first, then value. While it's not really imporant that
{2, Invalid} be considered to be less than {3, Invalid}, it's not a
problem either. This patch also implements operator== in terms of
operator<, so the two definitions will be kept in sync.

Reviewed By: sdesmalen

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

show more ...

[NFC] Remove min/max functions from InstructionCost

Removed the InstructionCost::min/max functions because it's
fine to use std::min/max instead.

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

[NFC] Remove min/max functions from InstructionCost

Removed the InstructionCost::min/max functions because it's
fine to use std::min/max instead.

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

show more ...

[Support] Introduce a new InstructionCost class

This is the first in a series of patches that attempts to migrate
existing cost instructions to return a new InstructionCost class
in place of a simpl

[Support] Introduce a new InstructionCost class

This is the first in a series of patches that attempts to migrate
existing cost instructions to return a new InstructionCost class
in place of a simple integer. This new class is intended to be
as light-weight and simple as possible, with a full range of
arithmetic and comparison operators that largely mirror the same
sets of operations on basic types, such as integers. The main
advantage to using an InstructionCost is that it can encode a
particular cost state in addition to a value. The initial
implementation only has two states - Normal and Invalid - but these
could be expanded over time if necessary. An invalid state can
be used to represent an unknown cost or an instruction that is
prohibitively expensive.

This patch adds the new class and changes the getInstructionCost
interface to return the new class. Other cost functions, such as
getUserCost, etc., will be migrated in future patches as I believe
this to be less disruptive. One benefit of this new class is that
it provides a way to unify many of the magic costs in the codebase
where the cost is set to a deliberately high number to prevent
optimisations taking place, e.g. vectorization. It also provides
a route to represent the extremely high, and unknown, cost of
scalarization of scalable vectors, which is not currently supported.

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

show more ...