On Wed, Oct 23, 2013 at 5:52 PM, Joseph S. Myers <jos...@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.
Note that we simply could make ABS_EXPR have defined behavior on overflow (wrapping). Of course you have to audit expanders whether they rely on undefined 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. Richard. > -- > Joseph S. Myers > jos...@codesourcery.com
