[Bug target/115086] New: bic is not used when the non-not part is a constant

[Bug target/115086] New: bic is not used when the non-not part is a constant

[pinskia at gcc dot gnu.org]

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

            Bug ID: 115086
           Summary: bic is not used when the non-not part is a constant
           Product: gcc
           Version: 15.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: enhancement
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
            Target: aarch64

Take:
```
int g2(int a,int c)
{
  int b = 4 & ~c;
  return b;
}
```

Currently GCC produces:
```
g2:
        mvn     w0, w1
        and     w0, w0, 4
        ret
```
But producing bic is better for most (if not all) modern cores due to the
instruction that generates the constant would be "free". That is GCC should
produce:
```
g2:
        mov     w8, 4
        bic     w0, w8, w1
        ret
```

Which is what clang/LLVM produces.

[Bug target/115086] bic is not used when the non-not part is a constant

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2024-05-14
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=112304
           Assignee|unassigned at gcc dot gnu.org      |pinskia at gcc dot gnu.org
             Status|UNCONFIRMED                 |ASSIGNED

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Trying 7 -> 13:
    7: r105:SI=~r106:SI
      REG_DEAD r106:SI
   13: x0:SI=r105:SI&0x4
      REG_DEAD r105:SI
Failed to match this instruction:
(set (reg/i:SI 0 x0)
    (and:SI (not:SI (reg:SI 106))
        (const_int 4 [0x4])))

So similar to what I did for csinc, PR 112304 so I will handle this.

[Bug target/115086] bic is not used when the non-not part is a constant

[rearnsha at gcc dot gnu.org]

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

--- Comment #2 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
And perhaps more importantly the mov can even be hoisted outside of a loop.

[Bug target/115086] bic is not used when the non-not part is a constant

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Richard Earnshaw from comment #2)
> And perhaps more importantly the mov can even be hoisted outside of a loop.

That won't be happening right away, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112304#c4 where cinc has the same
issue. In this case it is very similar in that we don't pull the constant from
the and (rather than add) inside LIM. Basically we don't have an early
"combine" to even generate the and/not pattern, forwprop could but I Have not
looked into why it does not and then we could do a split afterwards and LIM
might be able to pull it out. I will definitely look into that but that will
step 2 of this and the other issue.

[Bug target/115086] bic is not used when the non-not part is a constant

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
So looking into this a little bit. There are many different patterns which
might need to be fixed. Maybe there is a better way of implementing this into
forwprop. Let see if that is doable. But that won't be until next week.

[Bug target/115086] bic is not used when the non-not part is a constant

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #4)
> So looking into this a little bit. There are many different patterns which
> might need to be fixed. Maybe there is a better way of implementing this
> into forwprop. Let see if that is doable. But that won't be until next week.

I have a better idea than forwprop which I mentioned in a different bug report.
Basically add an andnot optab and expand using that if we can match it. the
open question is should we add an internal function and match it in
isel/math-opt pass and expand the internal function that way or add the code to
expand to match it. Either way the optab will be the same. 

Note that will fix even the pull the constant out of the loop issue too.