[Bug tree-optimization/116648] New: unswitch does not handle `if (a & b)` where a is invariant

[Bug tree-optimization/116648] New: unswitch does not handle `if (a & b)` where a is invariant

[pinskia at gcc dot gnu.org]

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

            Bug ID: 116648
           Summary: unswitch does not handle `if (a & b)` where a is
                    invariant
           Product: gcc
           Version: 15.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:
```
int ff(void);
int g(int a, int *tt, _Bool t1) {
  int c = 0;
  for (int e = 0; e < a; e++)
    {
      int h = 1;
      _Bool t2 = tt[e] != 0;
      if (t1 & t2)
        h = ff();
      c += h;
    }
  return c;
}
```


This could be unswitched as t1 is invariant but currently unswitch does not
handle it.

[Bug tree-optimization/116648] unswitch does not handle `if (a & b)` where a is invariant

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I should say I noticed this while looking into PR 116647.  Fixing this will
almost definitely make PR 116647 latent though.

[Bug tree-optimization/116648] unswitch does not handle `if (a & b)` where a is invariant

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
The issue is that unswitch sees

  _4 = *_3;
  t2_14 = _4 != 0;
  _12 = t2_14 & t1_15(D);
  if (_12 != 0)

and _12 isn't invariant.  Unswitch doesn't try to associate and unswitch
based on a partly invariant predicate - neither its analysis nor its
transform phase are set up to handle a case like this.

Eventually breaking out the invariant part of a combined condition to
a separate branch would be worthwhile since that branch is going to be
well-predicted while the combined one is likely not.  reassoc might
already associate a combined conditon in a way that this might be
straight-forward to do - in this case the expression is simple enough
of course.

Iff to be handled in unswitching directly I'd say it would need to key
on invariant bool uses and instead of handling only gcond and gswitch
handle assigns as well (with no obvious savings on code size of either
copy, thus less likely profitable). 

Confirmed.