[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