[Bug target/97042] New: powerpc64 UINT_MAX constant

[Bug target/97042] New: powerpc64 UINT_MAX constant

[amodra at gmail dot com]

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

            Bug ID: 97042
           Summary: powerpc64 UINT_MAX constant
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: amodra at gmail dot com
  Target Milestone: ---

/* -O2 -S */
long foo (long x) { return ~0u - x; }

for gcc-8 to current master
        lis 9,0xffff
        ori 9,9,0xffff
        rldicl 9,9,0,32
        subf 3,3,9
        blr

a regression from gcc-7
        li 9,-1
        rldicl 9,9,0,32
        subf 3,3,9
        blr

Both sequences give the same result, this is just a code quality regression.

I haven't properly debugged this but I suspect commit 5d3ae76af13

[Bug target/97042] powerpc64 UINT_MAX constant

[amodra at gmail dot com]

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

--- Comment #1 from Alan Modra <amodra at gmail dot com> ---
Yes, reverting 5d3ae76af13 cures this PR.

[Bug target/97042] powerpc64 UINT_MAX constant

[bergner at gcc dot gnu.org]

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

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

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

--- Comment #2 from Peter Bergner <bergner at gcc dot gnu.org> ---
With a patch I'm working on for PR93176, I get the following code (even with
the commit below):

        li 9,-1
        rldic 9,9,0,32
        subf 3,3,9
        blr

[Bug target/97042] powerpc64 UINT_MAX constant

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Created attachment 49214
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49214&action=edit
proposed patch for the ICEs

[Bug target/97042] powerpc64 UINT_MAX constant

[segher at gcc dot gnu.org]

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

Segher Boessenkool <segher at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #49214|0                           |1
        is obsolete|                            |
  Attachment #49214|proposed patch for the ICEs |proposed patch for the ICEs
        description|                            | (wrong PR, sorry)

--- Comment #4 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Comment on attachment 49214
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49214
proposed patch for the ICEs  (wrong PR, sorry)

>diff --git a/gcc/bb-reorder.c b/gcc/bb-reorder.c
>index 76e56b5..2ad5197 100644
>--- a/gcc/bb-reorder.c
>+++ b/gcc/bb-reorder.c
>@@ -2760,6 +2760,10 @@ duplicate_computed_gotos (function *fun)
>     if (computed_jump_p (BB_END (bb)) && can_duplicate_block_p (bb))
>       changed |= maybe_duplicate_computed_goto (bb, max_size);
> 
>+  /* Some blocks may have become unreachable.  */
>+  if (changed)
>+    cleanup_cfg (0);
>+
>   /* Duplicating blocks will redirect edges and may cause hot blocks
>     previously reached by both hot and cold blocks to become dominated
>     only by cold blocks.  */

[Bug target/97042] powerpc64 UINT_MAX constant

[segher at gcc dot gnu.org]

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

--- Comment #5 from Segher Boessenkool <segher at gcc dot gnu.org> ---
So hrm, why did GCC generate  lis 0xffff ; ori 0xffff ; rldicl  instead of
li 0xffff ; oris 0xffff  ?

[Bug target/97042] powerpc64 UINT_MAX constant

[amodra at gmail dot com]

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

--- Comment #6 from Alan Modra <amodra at gmail dot com> ---
That's easy.  rs6000_emit_set_long_const doesn't generate that sequence.

Incidentally, a patch I had to generate more constants from li;rldicl also
fixes this pr.

[Bug target/97042] powerpc64 UINT_MAX constant

[amodra at gmail dot com]

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

--- Comment #7 from Alan Modra <amodra at gmail dot com> ---
and of course, li 0xffff is li -1 which sets all bits.

[Bug target/97042] powerpc64 UINT_MAX constant

[segher at gcc dot gnu.org]

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

--- Comment #8 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Alan Modra from comment #7)
> and of course, li 0xffff is li -1 which sets all bits.

Erm, yes.  Duh.

So that g:5d3ae76af13 splitter should not fire for numbers that fit in
32 bits but that have the high bit of both 16-bit halfs set.

[Bug target/97042] powerpc64 UINT_MAX constant

[amodra at gmail dot com]

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

--- Comment #9 from Alan Modra <amodra at gmail dot com> ---
I think that splitter should disappear and rs6000_emit_set_long_const handle
all special cases where you might want combinations of two logical instructions
before handling the li;rldicl, li;rldicr or any other expansions with rotates.

[Bug target/97042] powerpc64 UINT_MAX constant

[segher at gcc dot gnu.org]

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

Segher Boessenkool <segher at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2020-09-15
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #10 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Alan Modra from comment #9)
> I think that splitter should disappear and rs6000_emit_set_long_const handle
> all special cases where you might want combinations of two logical
> instructions before handling the li;rldicl, li;rldicr or any other
> expansions with rotates.

Yeah, that would be much easier to read and maintain.  Good plan.