https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64946
--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> --- On Thu, 26 Feb 2015, vekumar at gcc dot gnu.org wrote: > 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? I don't see how it could.
