This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Vectorizing abs(char/short/int) on x86.


On Wed, Oct 23, 2013 at 8:52 AM, Joseph S. Myers
<joseph@codesourcery.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!

Cong


> --
> Joseph S. Myers
> joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]