[PATCH] D105108: [InstructionCost] Add saturation support.

Sander de Smalen via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jun 29 08:03:14 PDT 2021


sdesmalen added a comment.

In D105108#2847068 <https://reviews.llvm.org/D105108#2847068>, @dmgreen wrote:

> Looking at the documentation of invalid costs, it says
>
>   /// These states can currently be used to indicate whether a cost is valid or
>   /// invalid. Examples of an invalid cost might be where the cost is
>   /// prohibitively expensive and the user wants to prevent certain
>   /// optimizations being performed. Or perhaps the cost is simply unknown
>   /// because the operation makes no sense in certain circumstances. These
>   /// states can be expanded in future to support other cases if necessary.
>
> Do we have any examples of "Or perhaps the cost is simply unknown because the operation makes no sense in certain circumstances"? Where it wouldn't mean the same as an infinite cost.

If the IR has an operation with Invalid cost that would be considered a bug. That's because Invalid represents that an operation has no cost because it cannot be code-generated. If the cost is <very high>, that's fine although it suggests very inefficient. The former (Invalid) is true for scalable-vector operations that are not natively supported by the target and can only be lowered by scalarizing. SelectionDAG currently has no mechanism to do that, so any operation that requires scalarizing is considered to have an Invalid cost. Types like `<vscale x 1 x i128>` would be such an example for AArch64 SVE.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D105108/new/

https://reviews.llvm.org/D105108



More information about the llvm-commits mailing list