[Bug target/108004] New: x-form logical operations with dot instructions are not emitted.

[Bug target/108004] New: x-form logical operations with dot instructions are not emitted.

[guihaoc at gcc dot gnu.org]

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

            Bug ID: 108004
           Summary: x-form logical operations with dot instructions are
                    not emitted.
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: guihaoc at gcc dot gnu.org
  Target Milestone: ---

//test case
int foo (int a, int b, int c, int d)
{
  return (a & b) > 0 ? c : d;
}

//assemble on P9
        and 3,3,4
        cmpwi 0,3,0
        isel 5,5,6,1
        extsw 3,5

The "and" and "cmpwi" can be optimized to "and." instruction. The same as "or"
and "xor".

[Bug target/108004] x-form logical operations with dot instructions are not emitted.

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
From what I remember and. Only sets eq bit correctly.

[Bug target/108004] x-form logical operations with dot instructions are not emitted.

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Especially when it comes to signed comparisons.

[Bug target/108004] x-form logical operations with dot instructions are not emitted.

[guihaoc at gcc dot gnu.org]

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

--- Comment #3 from HaoChen Gui <guihaoc at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #2)
> Especially when it comes to signed comparisons.

From the ISA,
For all fixed-point instructions in which Rc=1, and for
addic., andi., and andis., the first three bits of CR Field
0 (bits 32:34 of the Condition Register) are set by
signed comparison of the result to zero, and the fourth
bit of CR Field 0 (bit 35 of the Condition Register) is
copied from the SO field of the XER.

[Bug target/108004] x-form logical operations with dot instructions are not emitted.

[guihaoc at gcc dot gnu.org]

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

--- Comment #4 from HaoChen Gui <guihaoc at gcc dot gnu.org> ---
$cat asm_test.c
#include <stdio.h>

unsigned long foo() {
  unsigned long res;
  __asm__ ("li 3,0xffffffffffffffff\n\t"
           "li 4,0xfffffffffffffff1\n\t"
           "and. 3,3,4\n\t"
           "mfcr %0"
           : "=r" (res));
  return res;
}

void
main()
{
  printf ("%lx\n", foo());
}
$ gcc -O1 -o asm_test asm_test.c && ./asm_test
82000482

Use the assembly to test the "and.". The bit32 (cr0 LT bit) is set when the
result is less than 0.

[Bug target/108004] x-form logical operations with dot instructions are not emitted.

[segher at gcc dot gnu.org]

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

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

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

--- Comment #5 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to HaoChen Gui from comment #0)
>         and 3,3,4
>         cmpwi 0,3,0
>         isel 5,5,6,1
>         extsw 3,5
> 
> The "and" and "cmpwi" can be optimized to "and." instruction. The same as
> "or" and "xor".

It cannot be "and.", that would do "cmpdi 3,0", and we want "cmpwi" here.

[Bug target/108004] x-form logical operations with dot instructions are not emitted.

[pinskia at gcc dot gnu.org]

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

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

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Using long instead of int gives:

        and. 4,3,4
        isel 3,5,6,1
        blr

Which is what you want there.
and. is incorrect for int as the upper bits are not defined for argument
passing ...

[Bug target/108004] x-form logical operations with dot instructions are not emitted.

[segher at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
         Resolution|INVALID                     |---
             Status|RESOLVED                    |SUSPENDED
   Last reconfirmed|                            |2023-01-09

--- Comment #7 from Segher Boessenkool <segher at gcc dot gnu.org> ---
It's not really invalid, but it won't happen any time soon.

The upper bits *are* defined for argument passing, in all our 64-bit ABIs:
for signed type (like here the value is passed sign-extended.  But the code
has "(a & b) > 0" which does the comparison as an int.  In combine we get

Trying 11 -> 14:
   11: r124:SI=r129:DI#4&r130:DI#4
      REG_DEAD r130:DI
      REG_DEAD r129:DI
   14: r125:CC=cmp(r124:SI,0)
      REG_DEAD r124:SI
Failed to match this instruction:
(set (reg:CC 125)
    (compare:CC (and:SI (subreg:SI (reg:DI 129) 4)
            (subreg:SI (reg:DI 130) 4))
        (const_int 0 [0])))

If we upgraded some stuff to DImode instead of SImode, sometimes we can
make better code, like we could here.  But in other cases the opposite is
true.  I think it is likely it helps more often than it would hurt, and we
can upgrade the mode only sometimes as well of course.

In any case, this is just a special case of a much more generic problem
(in all ports, not just rs6000!), that has been known for a very long time,
and no real progress has been made yet.  But it definitely should be doable.
To simplify the problem a lot it probably is okay to only consider upgrading
the mode of a pseudo everywhere (so not do it in some insns but not others),
and then assign a score to it.  Probably a higher score inside loops, that
is the case where we see this most / where we see it as a shortcoming most.

Where rs6000 is special here is that we have "w" and "d" (32-bit and 64-bit)
variants of many insns (but no smaller versions most of the time fwiw).