Re: [PATCH] Optimize (X<<C)+(Y<<C) as (X+Y)<<C for signed addition.

[Richard Biener <richard.guenther@gmail.com>]

On Wed, Sep 14, 2022 at 11:42 PM Marc Glisse via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> On Tue, 13 Sep 2022, Roger Sayle wrote:
>
> > This patch tweaks the match.pd transformation previously added to fold
> > (X<<C)+(Y<<C) as (X+Y)<<C that was previously restricted to unsigned
> > (wrapping) types, to also allow signed integer types provided that they
> > don't trap and the overflow needn't be preserved for sanitization.
> > i.e. this should now apply (by default) for "int x,y;", but is disabled
> > with -ftrapv.
>
> In https://gcc.gnu.org/onlinedocs/gcc/Integers-implementation.html , I
> read:
>
> "Bitwise operators act on the representation of the value including both
> the sign and value bits, where the sign bit is considered immediately
> above the highest-value value bit. Signed ‘>>’ acts on negative numbers by
> sign extension.
>
> As an extension to the C language, GCC does not use the latitude given in
> C99 and C11 only to treat certain aspects of signed ‘<<’ as undefined."

Oh, I wasn't aware of that.

> To me, this means that for instance INT_MIN<<1 is well defined and
> evaluates to 0. But with this patch we turn (INT_MIN<<1)+(INT_MIN<<1) into
> (INT_MIN+INT_MIN)<<1, which is UB.
>
> If we decide not to support this extension anymore, I think we need to
> change the documentation first.

Or perform the (X+Y) operation in an unsigned type.

Richard.

> --
> Marc Glisse