[Bug tree-optimization/114045] New: large _BitInt * _Bool (or having known boolean range) should be inlined instead of calling __mulbitint3

[Bug tree-optimization/114045] New: large _BitInt * _Bool (or having known boolean range) should be inlined instead of calling __mulbitint3

[pinskia at gcc dot gnu.org]

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

            Bug ID: 114045
           Summary: large _BitInt * _Bool (or having known boolean range)
                    should be inlined instead of calling __mulbitint3
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: enhancement
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
unsigned _BitInt(1024) 
foo (unsigned _BitInt(1024) ub1024_0, _Bool b)
{
  unsigned _BitInt(1024) t  = ub1024_0 * b;
  return t;
}

unsigned _BitInt(1024) 
foo2 (unsigned _BitInt(1024) ub1024_0 , _Bool b)
{
  unsigned _BitInt(1024) t = (unsigned _BitInt(1024))b;
  return ub1024_0 & -t;
}

unsigned _BitInt(1024) 
foo1 (unsigned _BitInt(1024) ub1024_0 , _Bool b)
{
  if (b)
    return ub1024_0;
  else
    return 0;
}
```

These should be both optimized the same.
One thing I noticed also is the copy loop for the return not optimized to just
memcpy but that is for a different issue.

Noticed when looking into PR 114040.

[Bug tree-optimization/114045] large _BitInt * _Bool (or having known boolean range) should be inlined instead of calling __mulbitint3

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
If it is really that beneficial, some optimization before bitint lowering
should lower it, dealing with such special cases in bitint lowering would
quickly make it unmaintainable, it is already quite complex on its own.
Note, even the multiplication isn't that expensive, we pass to the library that
one of the arguments has 1-bit unsigned precision (or the library could figure
it out if we don't see the range in the source), so it shouldn't be doing full
16 x 16 limb multiplication...

[Bug tree-optimization/114045] large _BitInt * _Bool (or having known boolean range) should be inlined instead of calling __mulbitint3

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
And, as for loops, we pattern recognize loops doing memcpy, memset, memmove
etc. later on.