This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Vectorizing abs(char/short/int) on x86.
- From: Cong Hou <congh at google dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Richard Biener <rguenther at suse dot de>
- Date: Wed, 23 Oct 2013 21:59:29 -0700
- 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> <CAK=A3=3-GYLuGa5Di7fD7Cr+Kj0P_nhWLBh2wetE7dB0w4X3uQ at mail dot gmail dot com>
I think I did not make it clear. If GCC defines that passing 128 to a
char value makes it the wrapping result -128, then the conversion from
(char) abs ((int) char_val) to abs (char_val) is safe if we can
guarantee abs (char(-128)) = -128 also. Then the subsequent methods
used to get abs() should also guarantee wrapping on overflow.
Shift-xor-sub is OK, but max(x, -x) is OK only if the result of the
negation operation on -128 is also -128 (wrapping). I think that is
right the behavior of SSE2 operation PSUBB ([0,...,0], [x,...,x]), as
PSUBB can operate both signed/unsigned operands.
On Wed, Oct 23, 2013 at 9:40 PM, Cong Hou <firstname.lastname@example.org> wrote:
> On Wed, Oct 23, 2013 at 8:52 AM, Joseph S. Myers
> <email@example.com> wrote:
>> 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.
> Yes, you are right. The method I use can guarantee wrapping on
> overflow (either shift-xor-sub or max(x, -x)). Can I just add the
> condition if (flag_wrapv) before the conversion I made to prevent the
> undefined behavior on overflow?
> Thank you!
>> Joseph S. Myers