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