[Bug tree-optimization/51492] vectorizer does not support saturated arithmetic patterns

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51492

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011-12-12
            Summary|vectorizer generates        |vectorizer does not support
                   |unnecessary code            |saturated arithmetic
                   |                            |patterns
     Ever Confirmed|0                           |1
           Severity|normal                      |enhancement

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-12 10:23:20 UTC ---
It's vectorized as

  vect_var_.11_17 = MEM[base: D.1616_5, offset: 0B];
  vect_var_.12_19 = vect_var_.11_17 + { 65472, 65472, 65472, 65472, 65472,
65472, 65472, 65472 };
  vect_var_.14_22 = VEC_COND_EXPR <vect_var_.11_17 > { 63, 63, 63, 63, 63, 63,
63, 63 }, vect_var_.12_19, { 0, 0, 0, 0, 0, 0, 0, 0 }>;
  MEM[base: D.1616_5, offset: 0B] = vect_var_.14_22;

GCC doesn't have the idea that this is a "saturated subtraction".  If targets
have saturated arithmetic support, but only with vectors, then the vectorizer
pattern recognition would need to be enhanced and the targets eventually
should support expanding saturated arithmetic.

OTOH middle-end support for saturated arithmetic needs to be improved,
scalar code could also benefit from optimization.  On the RTL level
we have [us]s_{plus,minus} which the vectorizer could use (if implemented
on the target for vector types).