This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Vectorizing abs(char/short/int) on x86.
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Cong Hou <congh at google dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Richard Biener <rguenther at suse dot de>
- Date: Wed, 23 Oct 2013 18:04:51 +0200
- Subject: Re: [PATCH] Vectorizing abs(char/short/int) on x86.
- Authentication-results: sourceware.org; auth=none
- References: <CAK=A3=3J2J_ZTT3qxO6z32kSNpA7dVFobYg=SQNi0udMY8E5VA at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1310231548200 dot 28882 at digraph dot polyomino dot org dot uk>
On Wed, Oct 23, 2013 at 5:52 PM, Joseph S. Myers
> On Tue, 22 Oct 2013, Cong Hou wrote:
>> For abs(char/short), type conversions are needed as the current abs()
>> function/operation does not accept argument of char/short type.
>> Therefore when we want to get the absolute value of a char_val using
>> abs (char_val), it will be converted into abs ((int) char_val). It
>> then can be vectorized, but the generated code is not efficient as
>> lots of packings and unpackings are envolved. But if we convert
>> (char) abs ((int) char_val) to abs (char_val), the vectorizer will be
>> able to generate better code. Same for short.
> ABS_EXPR has undefined overflow behavior. Thus, abs ((int) -128) is
> defined (and we also define the subsequent conversion of +128 to signed
> char, which ISO C makes implementation-defined not undefined), and
> converting to an ABS_EXPR on char would wrongly make it undefined. For
> such a transformation to be valid (in the absence of VRP saying that -128
> isn't a possible value) you'd need a GIMPLE representation for
> ABS_EXPR<overflow:wrap>, as distinct from ABS_EXPR<overflow:undefined>.
> You don't have the option there is for some arithmetic operations of
> converting to a corresponding operation on unsigned types.
Note that we simply could make ABS_EXPR have defined behavior on overflow
(wrapping). Of course you have to audit expanders whether they rely
behavior and you also have to audit existing foldings.
Undefined behavior on ABS_EXPR (INT_MIN) isn't as useful for optimization
as that on plus, minus and multiply. Similar for the integer division case.
> Joseph S. Myers