[Bug target/114429] New: [x86] (neg a) ashifrt>> 31 can be optimized to a > 0.

[Bug target/114429] New: [x86] (neg a) ashifrt>> 31 can be optimized to a > 0.

[liuhongt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114429

            Bug ID: 114429
           Summary: [x86] (neg a) ashifrt>> 31 can be optimized to a > 0.
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: liuhongt at gcc dot gnu.org
  Target Milestone: ---

typedef unsigned char uint8_t;
uint8_t x264_clip_uint8( int x )
{
    return x&(~255) ? (-x)>>31 : x;
}

void
foo (int* a, int* __restrict b, int n)
{
    for (int i = 0; i != 8; i++)
      b[i] = x264_clip_uint8 (a[i]);
}

gcc -O2 -march=x86-64-v3 -S


foo(int*, int*, int):
        ..
        mov     eax, 255
        vpxor   xmm0, xmm0, xmm0
        vmovd   xmm1, eax
        vpbroadcastd    ymm1, xmm1
        vmovdqu ymm2, YMMWORD PTR [rdi]
        vpminud ymm3, ymm2, ymm1
        vpsubd  ymm0, ymm0, ymm2
        vmovdqa YMMWORD PTR [rsp-32], ymm3
        vpsrad  ymm0, ymm0, 31
        vpcmpeqd        ymm3, ymm2, YMMWORD PTR [rsp-32]
        vpblendvb       ymm0, ymm0, ymm2, ymm3
        vpand   ymm1, ymm1, ymm0
        vmovdqu YMMWORD PTR [rsi], ymm1


It can be better with

        mov     eax, 255
        vmovd   xmm1, eax
        vpxor xmm0, xmm0, xmm0. 
        vpbroadcastd    ymm1, xmm1
        vmovdqu ymm2, YMMWORD PTR [rdi]
        vpminud ymm3, ymm2, ymm1
        vmovdqa YMMWORD PTR [rsp-32], ymm3
        vcmpgtps  ymm0, ymm2, ymm0
        vpcmpeqd        ymm3, ymm2, YMMWORD PTR [rsp-32]
        vpblendvb       ymm0, ymm0, ymm2, ymm3
        vpand   ymm1, ymm1, ymm0
        vmovdqu YMMWORD PTR [rsi], ymm1

[Bug target/114429] [x86] (neg a) ashifrt>> 31 can be optimized to a > 0.

[liuhongt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114429

Hongtao Liu <liuhongt at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |x86_64-*-* i?86-*-*

--- Comment #1 from Hongtao Liu <liuhongt at gcc dot gnu.org> ---
when x is INT_MIN, I assume -x is UD, so compiler can do anything.
otherwise, (-x) >> 31 is just x > 0.
From rtl view. neg of INT_MIN is assumed to 0 after it's truncated.
(neg:m x)
(ss_neg:m x)
(us_neg:m x)
These two expressions represent the negation (subtraction from zero) of the
value represented by x, carried out in mode m. They differ in the behavior on
overflow of integer modes. In the case of neg, the negation of the operand may
be a number not representable in mode m, in which case it is truncated to m.
ss_neg and us_neg ensure that an out-of-bounds result saturates to the maximum
or minimum signed or unsigned value.

so we can optimize (neg a)>>31 to a>0.

[Bug target/114429] [x86] (neg a) ashifrt>> 31 can be optimized to a > 0.

[liuhongt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114429

--- Comment #2 from Hongtao Liu <liuhongt at gcc dot gnu.org> ---
(In reply to Hongtao Liu from comment #1)
> when x is INT_MIN, I assume -x is UD, so compiler can do anything.
> otherwise, (-x) >> 31 is just x > 0.
> From rtl view. neg of INT_MIN is assumed to 0 after it's truncated.

Wait, is -INT_MIN truncated to INT_MIN? if that's case, we can't do the
optimization at rtl.

[Bug target/114429] [x86] (neg a) ashifrt>> 31 can be optimized to a > 0.

[liuhongt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114429

Hongtao Liu <liuhongt at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #3 from Hongtao Liu <liuhongt at gcc dot gnu.org> ---
Then invalid.