[llvm-dev] [Proposal] Introducing the concept of invalid costs to the IR cost model

Chris Tetreault via llvm-dev llvm-dev at lists.llvm.org
Thu Nov 5 11:23:20 PST 2020


You're being quite vague about what the extra state is. Is this because you haven't yet settled on what it should be, or do you actually intend to let it be a template parameter:

template <typename T>
struct Cost {
  unsigned Val;
  T State;
}

Thanks,
   Christopher Tetreault

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of David Sherwood via llvm-dev
Sent: Thursday, November 5, 2020 7:43 AM
To: llvm-dev at lists.llvm.org
Subject: [EXT] [llvm-dev] [Proposal] Introducing the concept of invalid costs to the IR cost model

Hi,

I'd like to propose a change to our cost interfaces so that instead of returning
an unsigned value from functions like getInstructionCost, getUserCost, etc., we
instead return a wrapper class that encodes an integer cost along with extra
state. The extra state can be used to express:

1. A cost as infinitely expensive in order to prevent certain optimisations
taking place. For example, there are already examples in LLVM where the cost is
set extremely high, but not so high that it would cause overflow. This might be to
prevent vectorisation in cases where we would have to scalarize the operation,
which is particularly relevant for scalable vectors, where scalarisation is
not [yet] available. There isn't currently a standard value for something that
constitutes very expensive and we can replace all the magic numbers with a
single invalid state.
2. A cost as unknown, where the user is simply unable to determine an accurate
cost for an operation.

This new wrapper class would work almost seamlessly with existing code as it
would contain the full set of operators required for arithmetic and comparisons.
This is in addition to the ability to create invalid costs and query the validity
of an existing cost. Once a cost becomes invalid or unknown it will remain in that
state regardless of any further arithmetic performed.

Kind Regards,
David Sherwood.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201105/6bf4a905/attachment.html>


More information about the llvm-dev mailing list