[PATCH] D68651: [InstCombine] Signed saturation patterns

Hideki Saito via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Oct 11 17:01:01 PDT 2019


hsaito added a comment.

In D68651#1704375 <https://reviews.llvm.org/D68651#1704375>, @kparzysz wrote:

> I'm in favor of treating signed saturation as canonical.  The issue in delaying detection of such cases to instruction selection is the volatility of the IR: there is no guarantee that the IR will remain in the same form (expected by isel) from one day to the next.  For example, some optimization may decide to just promote the operations to the wider type and only do the extension/truncate once, depending on how many saturating operations may be near one another.  Handling this variability in isel is just not feasible.


I don't want to hijack this review. Let me have the rest of the discussion in the form of RFC on llvm-dev. Vector idiom discussions resulted in ~20 idioms. It would be nice if we can come up with a basic guideline on how to think and how to make a case for the new canonical form. For example, TI said they are interested in saturating mul. If saturating add/sub have a canonical form, I don't see why saturating mul should not.


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

https://reviews.llvm.org/D68651





More information about the llvm-commits mailing list