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

[Dave Green via Phabricator via llvm-commits]

dmgreen added a comment.

>> 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.

OK that matches my expectation of an invalid cost. Synonymous with an infinite cost. It's not intended for something with a high cost, or something that we just haven't bothered to assign a cost to.
It may be worth updating the documentation to be more explicit about that, if we don't have any other ways we generate "invalid" costs.

As for this patch, I have no objections to adding saturation, but would not usually expect them to get that high (especially if the underlying type is an i64), except for some of the place in the vectorizer where we are multiplying by max tripcounts.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105108