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

            Bug ID: 123999
           Summary: [meta-bug] Signed int reassociation.
           Product: gcc
           Version: 16.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rdapp at gcc dot gnu.org
        Depends on: 35288, 88842, 111560, 113583, 122209
  Target Milestone: ---

As announced a while ago, this is a meta-bug for missed reassociation
optimizations due to signed overflow.  There are surely more but these
are the ones I had handy.

I have a proof-of-concept that enables ranger in reassoc and performs
a limited number of optimizations.  I haven't thought about a proper way
to easily include a range check in all optimizations reassoc performs, though.

There is some overlap with a missed optimization due to reassoc being unable
to un-distribute constants like in:

 t = t + 3 + 3 * t

Another idea to handle signed types in reassoc is to have reassoc run another
time, very late in the tree pipeline but with -fwrapv turned on.
In my opinion this would help but might miss some cases.
For the un-distribute example here we currently require ccp to run
after reassoc to fully optimize the function. 

The missed 519.lbm reassociation is pretty similar to the example above, just
for floating point and longer chains.

What we'd need to do at a concept level is allow constant factors in linearized
PLUS_EXPR operand lists.  Then un-distribute the factors when it makes sense.
I started that a while ago and it was a bit delicate to get all cases right.
We already have undistribute_ops_list and I found it difficult to have it
behave the way I want.  I'll try again for the next stage 1.

What's also missing and more involved (if at all possible), and not as part of
this meta-bug, is a more global reassoc that can perform CSE on sub-expressions
by e.g. counting their number of occurrence in an expression hash map.
Final reassociation of those would require a second (third) invocation of
reassoc or using a separate, new pass altogether.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35288
[Bug 35288] Expression reassociation problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88842
[Bug 88842] missing optimization CSE, reassociation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111560
[Bug 111560] Missed optimization of available expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113583
[Bug 113583] Main loop in 519.lbm not vectorized.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122209
[Bug 122209] reassoc? with bit masking

Reply via email to