On Mon, Mar 23, 2020 at 2:23 PM Stefan Schulze Frielinghaus via
Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
>
> Hi all,
>
> A rotate of a signed integer is not recognized so far.
>
> int32_t f (int32_t x)
> {
> return (x << 5) | (int32_t)((uint32_t)x >> 27);
> }
>
> The code above is unoptimized in contrast to a version consisting only
> of unsigned integers. I'm wondering if this is intended or not. Since
> GCC has well defined behavior for shifts where the first operand is
> signed, I assumed that this also holds for rotates.
>
> The attached patch adds a pattern to match.pd for such signed rotates.
> Any comments about this?
>
> Note, for the sake of simplicity the attached patch does not handle the
> case where the input is a signed integer and the result is an unsigned,
> i.e., the following case is not covered:
>
> uint32_t f (int32_t x)
> {
> return (x << 5) | ((uint32_t)x >> 27);
> }
>
> My gut feeling was that it's not worth it to have another pattern for
> such an impure rotate. Maybe I'm wrong?
I wonder if we can leverage the bswap pass for rotate detection
(see find_bswap_or_nop which matches the symbolic number
against either 1:1 or byte-swapped variants, to be added would be
rotate and shift patterns).
Richard.
> Cheers,
> Stefan
