https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64946
vekumar at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rguenth at gcc dot gnu.org
--- Comment #3 from vekumar at gcc dot gnu.org ---
Richard,
As per your suggestion, adding a pattern for type demotion in match.pd solves
this.
(simplify
( convert (abs (convert@1 @0)))
( if (INTEGRAL_TYPE_P (type)
/* We check for type compatibility between @0 and @1 below,
so there's no need to check that @1/@3 are integral types. */
&& INTEGRAL_TYPE_P (TREE_TYPE (@0))
&& INTEGRAL_TYPE_P (TREE_TYPE (@1))
/* The precision of the type of each operand must match the
precision of the mode of each operand, similarly for the
result. */
&& (TYPE_PRECISION (TREE_TYPE (@0))
== GET_MODE_PRECISION (TYPE_MODE (TREE_TYPE (@0))))
&& (TYPE_PRECISION (TREE_TYPE (@1))
== GET_MODE_PRECISION (TYPE_MODE (TREE_TYPE (@1))))
&& TYPE_PRECISION (type) == GET_MODE_PRECISION (TYPE_MODE (type))
/* The inner conversion must be a widening conversion. */
&& TYPE_PRECISION (TREE_TYPE (@1)) > TYPE_PRECISION (TREE_TYPE (@0))
&& ((GENERIC
&& (TYPE_MAIN_VARIANT (TREE_TYPE (@0))
== TYPE_MAIN_VARIANT (type)))
|| (GIMPLE
&& types_compatible_p (TREE_TYPE (@0), type))))
(abs @0)))
I have not yet tested it. Will it have implication on targets that does not
support vectorization with short/char types?
