The performance of saturating operations or adding intrinsics

Very nice! :+1:

I consider LoopVectorization.jl to be a “semi-standard” library, so I don’t see any problem with that feature being added to VectorizationBase.jl. Saturating arithmetic, however, is a concept orthogonal to vectorization.

I have (or I had) plans to add saturating_* to the CheckedArithmeticCore until Core, Base or stdlib supports saturating arithmetic (and for it to be available in past versions once it is supported).
cf. Add `saturating_*` and `wrapping_*` API definitons to `CheckedArithmeticCore` · Issue #9 · JuliaMath/CheckedArithmetic.jl · GitHub

This is an aside, but FixedPointNumbers#master implements the saturating_* functions instead of the saturated_*. The names are taken from Rust. Between checked_* and checking_*, I think the former is obviously more appropriate. (Rust uses the overflowing_* for checked arithmetic, and Rust’s experimental API supports *_with_overflow, though.) However I’m not sure which is better, saturating_* or saturated_*. (I prefer saturating_* in terms of not being able to determine whether it will or will not be saturated until the evaluation.)

I don’t think the name itself is very important (as we can use aliases :smile:), but I think we need to be cautious about the name collision because saturation arithmetic is a very “intrinsic” concept.