[Bug tree-optimization/116013] New: Missed optimization opportunity with andn involving consts

[Bug tree-optimization/116013] New: Missed optimization opportunity with andn involving consts

[bisqwit at iki dot fi]

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

            Bug ID: 116013
           Summary: Missed optimization opportunity with andn involving
                    consts
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bisqwit at iki dot fi
  Target Milestone: ---

Below are two short functions which work identically. While GCC utilizes the
ANDN instruction (of Intel BMI1) for test2, it fails to see that it could do
the same with test1.

    #include <stdint.h>
    uint64_t test1(uint64_t value)
    {
        return ~(value | 0x7F7F7F7F7F7F7F7F);
    }
    uint64_t test2(uint64_t value)
    {
        return ~value & ~0x7F7F7F7F7F7F7F7F;
    }

Assembler listings of both functions are below (-Ofast -mbmi):

    test1:
        movabsq $9187201950435737471, %rdx
        movq    %rdi, %rax
        orq     %rdx, %rax
        notq    %rax
        ret
    test2:
        movabsq $-9187201950435737472, %rax
        andn    %rax, %rdi, %rax
        ret

Tested compiler version:
GCC: (Debian 14-20240330-1) 14.0.1 20240330 (experimental) [master
r14-9728-g6fc84f680d0]

This optimization makes only sense if one of the operands is a compile-time
constant. If neither operand is a compile-time constant, then the opposite
optimization makes more sense — which GCC already does.
It is also worth noting, that GCC already compiles ~(var1 | ~var2) into ~var1 &
var2, utilizing ANDN. This is good.

[Bug middle-end/116013] Missed optimization opportunity with andn involving consts

[bisqwit at iki dot fi]

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

--- Comment #1 from Joel Yliluoma <bisqwit at iki dot fi> ---
Should be noted that this is not x86_64 specific; andn exists for other
platforms too, and even for platforms that don’t have it, changing
`~(expr|const)` into `~expr & ~const`   is unlikely to be a pessimization.

[Bug target/116013] Missed optimization opportunity with andn involving consts

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|middle-end                  |target
             Target|x86_64                      |x86_64-*-*

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
On the gimple level this is about canonicalization.  Now that we have a andn
optab RTL expansion/insn selection should do the trick but I wonder why
combine doesn't - that looks like a target bug or a simplify-rtx issue
(again a missed canonicalization rule?)

[Bug target/116013] Missed optimization opportunity with andn involving consts

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=111949
   Last reconfirmed|                            |2024-07-23

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The combine issue is:
```
Failed to match this instruction:
(set (reg:DI 101 [ _3 ])
    (and:DI (not:DI (reg:DI 104))
        (const_int -9187201950435737472 [0x8080808080808080])))
Successfully matched this instruction:
(set (reg:DI 102 [ _1 ])
    (not:DI (reg:DI 104)))
Failed to match this instruction:
(set (reg:DI 101 [ _3 ])
    (and:DI (reg:DI 102 [ _1 ])
        (const_int -9187201950435737472 [0x8080808080808080])))
```

which is very similar to PR 111949 and similar to PR 115086.

[Bug target/116013] Missed optimization opportunity with andn involving consts

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I have patches for part of this, though the optabs need to be renamed so the
backend changes have to wait until I finish that. and I need to also match ~(a
| CST) into `BIT_ANDC (~CST, a)` which I will add too.

[Bug target/116013] Missed optimization opportunity with andn involving consts

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #4)
> I have patches for part of this, though the optabs need to be renamed so the
> backend changes have to wait until I finish that. and I need to also match
> ~(a | CST) into `BIT_ANDC (~CST, a)` which I will add too.

Added that part of the patch to PR 115086. Once I change the optab name the x86
backend folks can implement the optabs and both of these will optimize now.

[Bug target/116013] Missed optimization opportunity with andn involving consts

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note I attached my patches to PR 115086 which fixes this for aarch64. All that
is needed after these patches get approved is either rename the current
patterns in the i386 backend to be andn<mode>3 and iorn<mode>3 and it will work
correctly. even for vector modes.