[Bug target/103743] New: PPC: Inefficient equality compare for large 64-bit constants having only 16-bit relevant bits in high part

[Bug target/103743] New: PPC: Inefficient equality compare for large 64-bit constants having only 16-bit relevant bits in high part

[jens.seifert at de dot ibm.com]

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

            Bug ID: 103743
           Summary: PPC: Inefficient equality compare for large 64-bit
                    constants having only 16-bit relevant bits in high
                    part
           Product: gcc
           Version: 8.3.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jens.seifert at de dot ibm.com
  Target Milestone: ---

int overflow();
int negOverflow(long long in)
{
   if (in == 0x8000000000000000LL)
   {
      return overflow();
   }
   return 0;
}

Generates:
negOverflow(long long):
        .quad   .L.negOverflow(long long),.TOC.@tocbase,0
.L.negOverflow(long long):
        li 9,-1
        rldicr 9,9,0,0
        cmpd 0,3,9
        beq 0,.L10
        li 3,0
        blr
.L10:
        mflr 0
        std 0,16(1)
        stdu 1,-112(1)
        bl overflow()
        nop
        addi 1,1,112
        ld 0,16(1)
        mtlr 0
        blr
        .long 0
        .byte 0,9,0,1,128,0,0,0

Instead of:
        li 9,-1
        rldicr 9,9,0,0
        cmpd 0,3,9

Expected output:
        rotldi 3,3,1
        cmpdi 0,3,1

This should be only applied if constant fits into 16-bit and if those 16-bit
are in the first 32-bit.

[Bug target/103743] PPC: Inefficient equality compare for large 64-bit constants having only 16-bit relevant bits in high part

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement

[Bug target/103743] PPC: Inefficient equality compare for large 64-bit constants having only 16-bit relevant bits in high part

[bergner at gcc dot gnu.org]

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

Peter Bergner <bergner at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pthaugen at gcc dot gnu.org

--- Comment #1 from Peter Bergner <bergner at gcc dot gnu.org> ---
Pat, does the patch from Alan you're working to get committed help with this
test case?

[Bug target/103743] PPC: Inefficient equality compare for large 64-bit constants having only 16-bit relevant bits in high part

[pthaugen at gcc dot gnu.org]

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

--- Comment #2 from pthaugen at gcc dot gnu.org ---
(In reply to Peter Bergner from comment #1)
> Pat, does the patch from Alan you're working to get committed help with this
> test case?

No, it just loads the constant slightly different:

        li 9,1
        rotldi 9,9,63
        cmpd 0,3,9

[Bug target/103743] PPC: Inefficient equality compare for large 64-bit constants having only 16-bit relevant bits in high part

[guojiufu at gcc dot gnu.org]

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

Jiu Fu Guo <guojiufu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |guojiufu at gcc dot gnu.org

--- Comment #3 from Jiu Fu Guo <guojiufu at gcc dot gnu.org> ---
For "in == 0x8000000000000000LL", it would be also ok with:
rotldi %r9,%r3,16
cmpldi %cr0,%r9,32768

And it would be similar for "in == 0x8000FFFFFFFFFFFFLL" (highest bit and
low48bits are all 1)
rotldi %r9,%r3,16
cmpdi %cr0,%r9,-32768

[Bug target/103743] PPC: Inefficient equality compare for large 64-bit constants having only 16-bit relevant bits in high part

[guojiufu at gcc dot gnu.org]

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

Jiu Fu Guo <guojiufu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |guojiufu at gcc dot gnu.org

--- Comment #4 from Jiu Fu Guo <guojiufu at gcc dot gnu.org> ---
rot(a)==rot(b_)==> a==rot(b')

[Bug target/103743] PPC: Inefficient equality compare for large 64-bit constants having only 16-bit relevant bits in high part

[guojiufu at gcc dot gnu.org]

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

--- Comment #5 from Jiu Fu Guo <guojiufu at gcc dot gnu.org> ---
It would be also ok for the constant that only has 16bits in the middle:
e.g. 0x0000098760000000ULL, we can rotate the constant to 0x9876.

[Bug target/103743] PPC: Inefficient equality compare for large 64-bit constants having only 16-bit relevant bits in high part

[guojiufu at gcc dot gnu.org]

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

--- Comment #6 from Jiu Fu Guo <guojiufu at gcc dot gnu.org> ---
Drafted a patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594702.html

[Bug target/103743] PPC: Inefficient equality compare for large 64-bit constants having only 16-bit relevant bits in high part

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jiu Fu Guo <guojiufu@gcc.gnu.org>:

https://gcc.gnu.org/g:1060cd2ad00b5174f4f8ef8ca3d8c283e321ffca

commit r13-4803-g1060cd2ad00b5174f4f8ef8ca3d8c283e321ffca
Author: Jiufu Guo <guojiufu@linux.ibm.com>
Date:   Tue Dec 20 11:43:57 2022 +0800

    rs6000: Optimize cmp on rotated 16bits constant

    Hi,

    When checking eq/ne with a constant which has only 16bits, it can be
    optimized to check the rotated data.  By this, the constant building
    is optimized.

    As the example in PR103743:
    For "in == 0x8000000000000000LL", this patch generates:
            rotldi 3,3,1 ; cmpldi 0,3,1
    instead of:
            li 9,-1 ; rldicr 9,9,0,0 ; cmpd 0,3,9

    Compare with previous version:
    https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600475.html.
    This patch refactor the code according to review comments.
    e.g. updating function names/comments/code.

    This patch pass bootstrap and regtest on ppc64 and ppc64le.
    Is it ok for trunk?  Thanks for comments!

    BR,
    Jeff(Jiufu)

            PR target/103743

    gcc/ChangeLog:

            * config/rs6000/rs6000-protos.h (can_be_rotated_to_lowbits): New.
            (can_be_rotated_to_positive_16bits): New.
            (can_be_rotated_to_negative_15bits): New.
            * config/rs6000/rs6000.cc (can_be_rotated_to_lowbits): New
definition.
            (can_be_rotated_to_positive_16bits): New definition.
            (can_be_rotated_to_negative_15bits): New definition.
            * config/rs6000/rs6000.md (*rotate_on_cmpdi): New
define_insn_and_split.
            (eqne): Move earlier.

    gcc/testsuite/ChangeLog:

            * gcc.target/powerpc/pr103743.c: New test.
            * gcc.target/powerpc/pr103743_1.c: New test.

[Bug target/103743] PPC: Inefficient equality compare for large 64-bit constants having only 16-bit relevant bits in high part

[guojiufu at gcc dot gnu.org]

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

Jiu Fu Guo <guojiufu at gcc dot gnu.org> changed:

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

--- Comment #8 from Jiu Fu Guo <guojiufu at gcc dot gnu.org> ---
Fixed now.