This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Generalize -(-X) a little
On Thu, Nov 2, 2017 at 2:11 PM, Marc Glisse <marc.glisse@inria.fr> wrote:
> On Thu, 2 Nov 2017, Richard Biener wrote:
>
>> On Wed, Nov 1, 2017 at 12:47 PM, Marc Glisse <marc.glisse@inria.fr> wrote:
>>>
>>> Hello,
>>>
>>> just a little tweak to that transformation. There is some overlap between
>>> the 2 versions, but it seemed easier to handle the NOP case (including
>>> the
>>> case without convert and the vector case) separately from the narrowing /
>>> sign-extending scalar integer case.
>>>
>>> At some point it would be good to have fold_negate_expr call
>>> generic_simplify so we could remove some transformations from
>>> fold-const.c.
>>>
>>> Bootstrap+regtest on powerpc64le-unknown-linux-gnu.
>>
>>
>> + (negate (convert (negate @1)))
>> + (if (INTEGRAL_TYPE_P (type)
>> + && (TYPE_PRECISION (type) <= TYPE_PRECISION (TREE_TYPE (@1))
>> + || (!TYPE_UNSIGNED (TREE_TYPE (@1))
>> + && TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@1))))
>> + && !TYPE_OVERFLOW_SANITIZED (type)
>> + && !TYPE_OVERFLOW_SANITIZED (TREE_TYPE (@1)))
>>
>> so I don't understand this fully -- a widening conversion is ok only for
>> signed types with undefined overflow? How does overflow come into play
>> here at all?
>
>
> Sign-extension is ok, as long as negate does what one expects. For INT_MIN,
> that's not the case.
>
> Consider -(long)(-INT_MIN). -INT_MIN is INT_MIN, cast to long it remains
> negative, and the final value is positive (assuming long is larger than
> int), while (long)INT_MIN is negative.
>
> Undefined overflow allows us to assume that X is not INT_MIN. I could
> instead query VRP (and teach VRP that NEGATE_EXPR of VARYING has range
> [-INT_MAX,INT_MAX] with undefined overflow), but that seems a bit
> overkill.
>
>> The testcase doesn't tell ...
>
>
> Probably I should add a second testcase with cases that must not be
> simplified. Maybe even a runtime test for INT_MIN...
>
>> For floats eliding any conversion should be ok if not flag_rounding_math
>> and flag_unsafe_math_optimizations (we remove a rounding step)?
>
>
> I was leaving that for another time (currently this is handled differently
> in fold-const.c), but ok.
>
> For true floats (not fixed point), any extension seems fine, and narrowing
> indeed requires !HONOR_SIGN_DEPENDENT_ROUNDING (on the smaller type). It
> isn't clear to me that we need flag_unsafe_math_optimizations, with
> round-to-nearest -(float)(-dbl) does look equivalent to (float)dbl.
>
> I'll post a new patch with floats and more testcases when I get the time.
You can handle floats as followup but some testcases that shouldn't be optimized
for the INT_MIN / unsigned case would be nice.
Richard.
> --
> Marc Glisse